----- Original Message -----
From: Elijah Newren
Date: 8/27/2010 12:46 PM
On Fri, Aug 27, 2010 at 9:48 AM, Joshua Jensen
<jjensen@xxxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html