On Wed, Feb 16, 2011 at 1:37 AM, Martin von Zweigbergk
<martin.von.zweigbergk@xxxxxxxxx> wrote:
> On Tue, 15 Feb 2011, Santi B?jar wrote:
>
>> On Mon, Feb 14, 2011 at 1:51 PM, Martin von Zweigbergk
>> <martin.von.zweigbergk@xxxxxxxxx> wrote:
>> > 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
>> > simulates one step of "reflog walking" by keeping track of the
>> > position of the remote-tracking branch before and after the fetch
>> > operation. This does not rely on reflogs. 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 (as in '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
>> > as a kind of '$upstream@{1}'.
>>
>> I don't agree with point b). In line 190:
>>
>> remoteref="$(get_remote_merge_branch "$@" 2>/dev/null)" &&
>>
>> It returns the local tracking branch for repo=origin and branch=master
>> and uses its reflog.
>
> Yes, but the local tracking branch is not updated when the
> two-argument version of 'git pull' is used [1].
Yes, but the reflog is used nevertheless and it can use the local
tracking branch as the old-remote-hash.
>
>> The end result is the same, there is one case where you need the old
>> value of the tracking branch, so it should be done in git-pull.
>
> True, case a) is still there. I was just trying to explain why I
> didn't just move the code from git-pull.sh to git-rebase.sh, but maybe
> it confused more than it clarified...
Yes, with only case a) is sufficient (and complete).
HTH,
Santi
--
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