On Sat, Nov 13, 2010 at 6:30 PM, Santi BÃjar <santi@xxxxxxxxxxx> wrote:
> On Fri, Nov 12, 2010 at 9:11 PM, Martin von Zweigbergk
> <martin.von.zweigbergk@xxxxxxxxx> wrote:
>> Since c85c792 (pull --rebase: be cleverer with rebased upstream
>> branches, 2008-01-26), 'git pull --rebase' has used the reflog to try to
>> rebase from the old upstream onto the new upstream.
>>
>> However, if, instead of 'git pull --rebase', the user were to do 'git
>> fetch' followed by 'git rebase @{upstream}', the reflog would not be
>> walked. This patch teaches "git rebase" the same reflog-walking tricks
>> that 'git pull --rebase' already knows.
>>
>> Apart from making 'git rebase' better aligned with 'git pull --rebase',
>> this may also be useful on its own for rebasing one branch against
>> another local branch that has been rebased. Currently, you would have to
>> do that using 'git rebase --onto' or by configuring it on the branch.
>>
>> It might seem like most of the related code in git-pull.sh can be
>> removed once git-rebase.sh supports reflog walking. Unfortunately, not
>> much of it can be removed, though. The reason is that git-pull.sh does
>> one step of 'reflog' walking even when the reflog is not used. There are
>> at least two cases where the reflog is not used: a) when it is disabled,
>> b) when the remote branch was specified on the command line (let's say
>> 'git pull --rebase origin master'). In both of these cases, git-pull.sh
>> remembers the position of the reference before the fetch and uses that
>> in place of '$ref@{1}'.
>
> In the code I don't see when b) is different to call it without
> command line branches. And if it is different I suppose it is a bug.
The difference is somewhere in the code for 'git fetch'. I'm trying to
refer to the same thing as I did in
http://thread.gmane.org/gmane.comp.version-control.git/160004/focus=160939.
> The code must stay in git-pull.sh because there it has more
> information (commit before and after fetch) than in git-rebase,
> essentially when reflogs are disabled.
Yes, I think that's what I meant by reason 'a)', but maybe I could have
explained it in a better way.
--
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