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.
--
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