Chris
Chris

Reputation: 1697

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 topic onto 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 E and E'?

Upvotes: 12

Views: 3058

Answers (4)

Eugen Konkov
Eugen Konkov

Reputation: 25133

In your question you want to move starting from C commit. B is left as branch based on A.

First we should give name to it:

git branch -b some_unfinished_feature <B-ish>

This command will create some_unfinished_feature branch starting from <B-ish> commit.

The <C-ish> is upstream. You can view all commits that would be rebased:

git log <C-ish>..topic

You can notice that I and J will not be rebased because those are different branch. You should rebase it separately later.

Now rebase your topic onto <A-ish> starting from <C-ish>:

git rebase -p --onto <A-ish> <C-ish> topic

-p flag will preserve any merges which occur from <C-ish> to topic

When this command complete you will get:

       some_unfinished_feature
     /
A---B---C---D---E---I---J master
  \
   C`---D`---E`
              \   
                F`---G`---H` topic

Now you should rebase master onto <E-ish> from <I-ish>

git rebase -p --onto <E-ish> <I-ish> master

Voila:

A---B some_unfinished_feature
  \
   C`---D`---E`--I`---J` master
              \   
                F`---G`---H` topic

Upvotes: 1

Sebastien
Sebastien

Reputation: 1476

               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 ;)

Upvotes: 2

LeGEC
LeGEC

Reputation: 51820

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.

If your 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.

Upvotes: 0

Karl Bielefeldt
Karl Bielefeldt

Reputation: 49018

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.

Upvotes: 0

Related Questions