git rebase and keep all child branches
I’m trying to import a CVS repository into git. Unfortunately, we’ve been using a really old method of creating releases from our CVS repo, that doesn’t involve any actual CVS branches or tags, but keep that information in a separate system. Consequently, almost all of the development happens on the CVS trunk. So, one file may be added very early in the history, but doesn’t become part of the release for 6 months.
What I’d like to do is import this CVS repo into git, and use rebasing to move these commits to development branches. I do have some branches from CVS though, so I really want to move all branches.
Say I’ve got this:
F---G---H topic / A---B---C---D---E---I---J master
B is the commit that I want to move to its own branch. I want the result to look like this:
F`---G`---H` topic / A---C`---D`---E`---I`---J` master \ B some_unfinished_feature
But rebasing only
master results in:
git checkout -b some_unfinished_feature B git rebase --onto A B master A---C`---D`---E`---I`---J` master \ \ F---G---H topic \ / B---C---D---E \-some_unfinished_feature
Can I get git to rebase
E' in one rebase command? I could potentially have lots of branches that I want to move onto their corresponding new commit. Or is there a way that I can get a mapping between
3 Solutions collect form web for “git rebase and keep all child branches”
F---G---H topic / A---B---C---D---E---I---J master git checkout B git branch BRANCH-B git checkout master git rebase -i HEAD~6
(remove commit B)
git rebase --onto D' D topic
This should do it assuming no conflict 😉
The command to move
topic would be:
git rebase --onto E' E topic
Unfortunately, there’s no way to do this automatically for a bunch of different branches, and that is by design. Each rebase potentially introduces conflicts that must be resolved manually.
Alternately, you might be able to use git filter-branch with your configuration management software to script the changes you want, but that’s potentially a lot of work. It might make more sense to keep
master as your development branch, and use
filter-branch to make a release branch, rather than the other way around.
First, a word of advice : when reabasing, work with a temporary branch :
git branch wip_topic git checkout wip_topic
Once you have a successful rebase (and checked that it works…), you can move your original head to the working commit :
git checkout topic git reset --hard wip_topic git branch -d wip_topic
(if you didn’t and something bad happens,
git reflog can still save your bacon …)
When doing a rebase, git skips commits where the commit’s textual diff matches an existing commit on the target branch.
master rebase did not introduce too many conflicts, applying :
git rebase --onto A B wip_topic
should give you the desired result.
Generally, most conflicts will appear near the “beginning” of the rebased commit list (<– pinch of salt).
Say you had conflicts when building commit
C', but none afterwards, you can rebase the
C..topic part :
git rebase --onto C' C wip_topic
Anyhow : try it, and see what
git‘s black magic does.