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

[Joshua Jensen <jjensen@workspacewhiz.com>]

  ----- Original Message -----
From: Elijah Newren
Date: 8/27/2010 12:46 PM
> 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?

Josh