tags:

views:

100

answers:

2

I use a lot of local topic branches in git, and sometimes end up with dependencies between topic branches causing rebase problems. For example, with a structure like:

master ---> featureA ---> featureB
                     \--> featureC

If master changes and I get (and resolve) conflicts when rebasing featureA, then afterwards rebasing featureB onto featureA triggers the same conflicts (and sometimes exciting new ones as well) because it tries to reapply the patches from the featureA branch. Assuming that the actual patches between featureA and featureB would apply cleanly if cherry-picked, is there a way of doing a rebase in this situation with roughly the same effect as cherry-picking all of the commits between featureA and featureB?

+8  A: 

After rebasing featureA, you can do

git rebase --onto featureA oldFeatureA featureB

assuming oldFeatureA represents the commit at the tip of featureA before you rebased it (you can either keep another branch there or just remember the commit hash).

This should basically be the same as cherry-picking each commit between A and B onto the rebased version of A.

Documentation on git-rebase (includes some helpful pictorial explanations of what happens during some more complex rebase operations)

Phil
Excellent, thanks. I'd figured out that --onto looked like it should do the job, but using the old tip as a base didn't occur to me.
Kai
Instead of `oldFeatureA`, it should be possible to use `featureA@{1}`, assuming that the rebase was the last change to that branche. Otherwise use something like `@{2}`, `@{3}`, or `@{one hour ago}`
Ropez
+1  A: 

For the future, if you work with lot of interdependent topic branches, perhaps you should consider using TopGit (README), a tool to manage patch queue using Git topic branches, one patch per branch; or alternatively a tool to manage multiple topic branches.

See e.g. topgit Means Never Having to Wait for Reviews blog posts.

Jakub Narębski