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

  ----- Original Message -----
From: Elijah Newren
Date: 8/27/2010 12:46 PM

On Fri, Aug 27, 2010 at 9:48 AM, Joshua Jensen
[off-list ref]  wrote:

quoted

quoted

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