Re: [PATCH] rebase: be cleverer with rebased upstream branches

On Wed, Feb 16, 2011 at 1:37 AM, Martin von Zweigbergk
[off-list ref] wrote:

On Tue, 15 Feb 2011, Santi B?jar wrote:

quoted

On Mon, Feb 14, 2011 at 1:51 PM, Martin von Zweigbergk
[off-list ref] wrote:

quoted

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.

quoted

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