18

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?

Kai
  • 5,260
  • 5
  • 29
  • 36
  • See also [how I'd rebase a whole subhistory -- several branches, with some links between them resulting from merge](http://stackoverflow.com/a/9706495/94687). The unpleasant part of that solution is the need to reset the topic branch refs to the new rebased commits afterwards. – imz -- Ivan Zakharyaschev Mar 14 '12 at 21:58

3 Answers3

20

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)

Jakub Narębski
  • 309,089
  • 65
  • 217
  • 230
Phil
  • 4,767
  • 1
  • 25
  • 21
  • 1
    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 Oct 10 '09 at 00:51
  • 5
    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 Jun 25 '10 at 08:38
6

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
  • 309,089
  • 65
  • 217
  • 230
  • Thanks for pointing at TopGit! TopGit seems to aim at the right thing: maintaining interdependent branches. **But does TopGit has the feature to rebase my interdependent topic branches onto a new upstream state?** If it could, I could use TopGit to develop and prepare my patches as branches for a review and possible pulling by the upstream. – imz -- Ivan Zakharyaschev Mar 14 '12 at 22:02
  • See also [Some discussion about a "rebase-based TopGit"](http://git.661346.n2.nabble.com/Branch-dependencies-td6641429.html): " I think a new 'system' needs to be 'rebase' based, not merge based like TopGit" – imz -- Ivan Zakharyaschev Mar 14 '12 at 22:30
0
git rebase -–update-refs

(after Git 2.38)

vmlinuz
  • 11
  • 4