Re: Unexpected/unexplained difference between git pull --rebase and git rebase

[John Keeping <john@keeping.me.uk>]

On Tue, Mar 03, 2015 at 12:39:31PM -0800, Mike Botsko wrote:
> I'm seeing unexpected behavior between "git pull --rebase" and "git
> rebase" commands, which are supposed to be (and always described as)
> synonymous:
> 
> git pull --rebase upstream our-branch-name
> 
> and
> 
> git fetch upstream
> git rebase upstream/our-branch-name
> 
> We have a situation where the upstream/our-branch-name was rebased, to
> incorporate changes from master. Somehow, the person who did the
> rebase discarded a merge commit:
> 
> 634b622 Sue Merge pull request #254 from bob/B-07290
> bc76e5b Bob [B-07290] Order Parts Ship To/Comments
> 
> became:
> 
> c1452be Sue [B-07290] Order Parts Ship To/Comments
> 
> 
> A developer who had a local branch tried to rebase their work (a
> single commit on top of that feature branch).
> 
> At the moment, his now-out-of-date branch looks like this:
> 
> 92b2194 Rick B-07241
> 634b622 Sue Merge pull request #254 from dboyle/B-07290
> bc76e5b Bob [B-07290] Order Parts Ship To/Comments
> 
> I've done some debugging, and the above "git pull" command generates
> the following and sends it to eval():
> 
> git-rebase --onto c1452be62cf271a25d3d74cc63cd67eca51a127d
> 634b622870a1016e717067281c7739b1fe08e08d
> 
> This process works perfectly. The old commits are discarded and his
> branch now correctly reflects upstream/our-branch-name, with his
> single new commit at the top.
> 
> 
> However, if he runs the "git rebase" command above, several of the
> commits that have changed hashes (they've also changed patch id
> slightly, because during the rebase someone fixed a merge conflict)
> are treated as new work, and git tries to re-apply them and we get
> tons of merge conflicts.
> 
> The git rebase command above is trying to rebase onto:
> 
> revisions = c1452be62cf271a25d3d74cc63cd67eca51a127d..92b2194e3adc29eb3fadd93ddded0ed34513d587
> 
> 
> These two features should work the same, yet one is choosing a
> different commit hash than the other.
> 
> If this is not a bug, I can't find anyone who can explain what's
> happening. I'm using git 2.2.1 on mac, but other people on our team
> have a variety of older versions and we're all seeing the same result.

What version of Git are you using?

Does it work if you add the `--fork-point` argument to git-rebase?  If
so, does it do the same if you just do "git rebase" with no arguments
(see the documentation of `--fork-point` in git-rebase(1) for details of
this)?