Question

I have encountered an interesting issue in which I have my master trying to catch up with an upstream branch. However I want to test my master at specific points along the way so I ensure I only rebase upstream onto master at certain points.

Assume the following state:

          --F--G--H--> master
         /
        /
----A--B--C--D--E--I--J--> upstream

I want first to rebase C and D and then test. So I do:

$ git checkout upstream
$ git checkout D
$ git checkout -b upstreamD
$ git rebase -i master
$ git checkout master
$ git merge upstreamD

This shows me C and D to rebase. After successful rebase I have:

          --F--G--H--C--D--> master
         /
        /
----A--B--C--D--E--I--J--> upstream
             ^
         upstreamD

Then I removed upstream cause I didn’t need it anymore while testing, etc (cause I can always get it).

$ git branch -d upstreamD
$ git branch -d upstream
$ git remote rm upstream

I do my testing and since everything is fine I go back and grab my upstream using a newly created remote and put its master in branch upstream.

So, now I think I have something like (notice master and upstream have more commits):

          --F--G--H--C--D--K--L--> master
         /
        /
----A--B--C--D--E--I--J--M--N--> upstream

And I want to rebase a bit more so I execute the same procedure above:

$ git checkout upstream
$ git checkout J
$ git checkout -b upstreamJ
$ git rebase -i master

However, now I get to rebase something like: C, E, I, J. The strange thing is that I was only expecting E, I, J. C is in master already (even if under a different SHA1, since history is different).

In http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html it says and I quote:

If the upstream branch already contains a change you have made (e.g.,
because you mailed a patch which was applied upstream), then that
commit will be skipped.

I couldn’t find anywhere where it explains how git performs this skipping. How does it check that C is already in master or not, and why does it decide that C should be rebased again and D shouldn’t?

Answer 1

From git-rebase(1):

Note that any commits in HEAD which introduce the same textual changes as a commit in HEAD.. are omitted (i.e., a patch already accepted upstream with a different commit message or timestamp will be skipped).

(Which seems to be implemented via git format-patch, specifically the --ignore-if-in-upstream option.)

This means that the patches must be textually identical (only the patches, not the commit metadata or SHA id’s, etc.) for rebase to skip them automatically.

I suspect in your example above that commit C likely had a conflict which you had to resolve; as a result of this the patches would be different. If commit D did not conflict, it would still be textually identical, hence why rebase skipped it when it did not skip C.

In my opinion the best way to handle this scenario is to use the --onto option for git rebase, like so:

git rebase --onto master D

Where D is the last commit you rebased. There are other ways; rebasing interactively and removing the commits that you know already exist is one.

I consider the automatic skipping logic of git rebase to be a “best effort” one; when it works it’s great, but as you’ve seen you have to be prepared for the cases when it doesn’t.

HTH.