git pull --rebase differs in behavior from git fetch + git rebase

> I have a case where 'git pull --rebase' does not do the Right Thing 
> (according to me).
>
> If I run 'git rebase origin/master', that rebase does the right thing, 
> perfectly reapplying my *single* commit on top of the upstream.
>
> 'git pull --rebase' ends up reapplying a bunch of much earlier commits and 
> ends up with a conflict.
>
> The documentation for git pull --rebase states: "Instead of a merge, perform 
> a rebase after fetching. If there is a remote ref for the upstream branch, 
> and this branch was rebased since last fetched, the rebase uses that 
> information to avoid rebasing non-local changes."  I do not understand
>
> I'm studying the git-pull script right now, but I have to admit this is 
> beyond me.  I'm sure if I stare hard enough, I'll get it.
>
> I mistakenly have assumed 'git pull' = 'git fetch; git merge' and that 'git 
> pull --rebase' = 'git fetch; git rebase'.  Does anyone want to clarify what 
> is really going on?  Unfortunately, I can't publish the repository in 
> question.

> On Thu, 26 Aug 2010, Joshua Jensen wrote:
>
>> I have a case where 'git pull --rebase' does not do the Right Thing 
>> (according to me).
>>
>> If I run 'git rebase origin/master', that rebase does the right 
>> thing, perfectly reapplying my *single* commit on top of the upstream.
>>
>> 'git pull --rebase' ends up reapplying a bunch of much earlier 
>> commits and ends up with a conflict.
>>
>> The documentation for git pull --rebase states: "Instead of a merge, 
>> perform a rebase after fetching. If there is a remote ref for the 
>> upstream branch, and this branch was rebased since last fetched, the 
>> rebase uses that information to avoid rebasing non-local changes."  I 
>> do not understand
>>
>> I'm studying the git-pull script right now, but I have to admit this 
>> is beyond me.  I'm sure if I stare hard enough, I'll get it.
>>
>> I mistakenly have assumed 'git pull' = 'git fetch; git merge' and 
>> that 'git pull --rebase' = 'git fetch; git rebase'.  Does anyone want 
>> to clarify what is really going on?  Unfortunately, I can't publish 
>> the repository in question.
>
> Are you by any chance running a git with commit cf65426de?  If not, give
> it a try and see if it corrects your issue.

> The main difference between "git pull --rebase" and "git fetch && git
> rebase @{u}" is that "git pull --rebase" will attempt to use the reflog
> to find a suitable "upstream" candidate instead of assuming your
> tracking branch is the upstream itself.  This is intended to help
> recover from upstream rebases, but has adverse effects sometimes, which
> commit cf65426de should help with.

>> The main difference between "git pull --rebase" and "git fetch && git
>> rebase @{u}" is that "git pull --rebase" will attempt to use the reflog
>> to find a suitable "upstream" candidate instead of assuming your
>> tracking branch is the upstream itself.  This is intended to help
>> recover from upstream rebases, but has adverse effects sometimes, which
>> commit cf65426de should help with.
>
> Unfortunately, commit cf65426de helps only a little.  The 'git pull
> --rebase' reports "Nothing to do" and moves the master branch to
> origin/master, leaving behind the commit needing to be rebased.
>
> What else might there be to try?  I would like to help with a repro, if
> possible.

> On Fri, Aug 27, 2010 at 9:48 AM, Joshua Jensen
> <jjensen@workspacewhiz.com>  wrote:
>>> The main difference between "git pull --rebase" and "git fetch&&  git
>>> rebase @{u}" is that "git pull --rebase" will attempt to use the reflog
>>> to find a suitable "upstream" candidate instead of assuming your
>>> tracking branch is the upstream itself.  This is intended to help
>>> recover from upstream rebases, but has adverse effects sometimes, which
>>> commit cf65426de should help with.
>> Unfortunately, commit cf65426de helps only a little.  The 'git pull
>> --rebase' reports "Nothing to do" and moves the master branch to
>> origin/master, leaving behind the commit needing to be rebased.
>>
>> What else might there be to try?  I would like to help with a repro, if
>> possible.
> Try modifying the git-pull script; change the last line from
>    eval "exec $eval"
> to
>    echo "exec $eval"
> .
>
> Is the output of the form
>    git-rebase --onto XXXX YYYY
> or
>    git-rebase --onto XXXX XXXX
> ?
>
> With cf65426de, and from what I'm guessing from your description, I'd
> expect the latter.  And, I'd assume the latter is equivalent to
> 'git-rebase XXXX', but you say that's not the behavior you're getting.
>   Finding out which of my assumptions is wrong may help you debug the
> issue.

> It reports to me 'git-rebase --onto XXXX XXXX'.
>
> And it reports nothing to do.
>
> XXXX is properly the origin/master in this case.
>
> git rebase origin/master           works.
> git rebase --onto origin/master origin/master       does not work.
>
> Thoughts?

> On Fri, Aug 27, 2010 at 4:29 PM, Joshua Jensen
> <jjensen@workspacewhiz.com>  wrote:
>> It reports to me 'git-rebase --onto XXXX XXXX'.
>>
>> And it reports nothing to do.
>>
>> XXXX is properly the origin/master in this case.
>>
>> git rebase origin/master           works.
>> git rebase --onto origin/master origin/master       does not work.
>>
>> Thoughts?
> It's too bad you can't make this repository public; I thought rebase
> should behave the same for those two commands.  We could certainly
> just modify git-pull.sh to avoid using the --onto flag when
> oldremoteref is not defined (and perhaps that makes sense independent
> of anything else), but I'm curious now about rebase.
>
> Can you insert an echo statement right before where git-rebase calls
> format-patch to see what arguments it is passing in those two cases?
> For me it's around line 568; insert an echo statement so that it looks
> like:
>   if test -z "$do_merge"
>   then
>          echo git format-patch -k --stdout --full-index --ignore-if-in-upstream \
>                 --no-renames $root_flag "$revisions"
>          git format-patch -k --stdout --full-index --ignore-if-in-upstream \
>                  --no-renames $root_flag "$revisions" |
>          git am $git_am_opt --rebasing --resolvemsg="$RESOLVEMSG"&&
> Make that change, and then run it with both your rebase commands and
> see what you get.
>
> For me, in both cases, I get:
>    git format-patch ... --no-renames origin/master..HEAD
> (except sha1sums of what origin/master and HEAD were rather than that
> literal text), which means the same patches are being applied in both
> cases for me.

> On Fri, Aug 27, 2010 at 8:06 PM, Joshua Jensen
> <jjensen@workspacewhiz.com>  wrote:
>> Okay, there is _not_ a problem with the patch in 1.7.2.2 for the "broken"
>> repository I have in front of me right now, but I wish I hadn't trashed the
>> other broken repository someone else had.  :(

>> Sorry for causing an issue, but I definitely appreciate the fix already
>> being available.
> Not a problem; it's totally understandable.  Believe me, I had a whole
> bunch of similar problems when trying to deal with this bug when
> people were hitting it at work (e.g. trying to duplicate by cloning,
> which never worked since the bug depended on reflog state).