1

I want to know, if you use

git rebase --preserve-merges

what is the exact list of commits that rebase attempts to play back.

To be more concrete, say I have topic and master branches. Previously there were some merges from master into topic (so topic wouldn't get unnecessarily far from master). Since then there have been some additional commits on topic.

Suppose now I now rebase topic on master like so:

git checkout topic
git rebase --preserve-merges master

What is the exact set of commits that git will store in the rebase "temporary area" and then reapply on top of master?

Extra credit if the answer generalizes to use of --onto and other parameters.

For comparison, "git help rebase" is clear that the set of commits to reapply is given by <upstream>..HEAD (in our case master..topic)

Chris
  • 9,986
  • 8
  • 48
  • 56
  • See also http://stackoverflow.com/questions/15915430/what-exactly-does-gits-rebase-preserve-merges-do-and-why – Chris Apr 21 '13 at 05:29

1 Answers1

0

It seems to be approximately along the lines of

git log --ancestry-path `git merge-base master topic`..topic

(That is, find the merge-base between the two branches, and find the commits between it and topic.)

It's not quite right, though. In my repo this generates a very similar list of commits to what rebase --preserve-merges uses, but it's not identical. (e.g. the total # of commits is not quite the same.)

Chris
  • 9,986
  • 8
  • 48
  • 56