From: Elijah Newren <newren@gmail.com>
Date: Fri, 27 Aug 2010 18:46:53 GMT
Subject: Re: git pull --rebase differs in behavior from git fetch + git rebase
Message-ID: <AANLkTimEO==c7Pzi99VfvDp7S9HN=V2j6t0kk--w1kb9@mail.gmail.com>
In-Reply-To: <4C77DE60.6020809@workspacewhiz.com>

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.