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

[Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>]

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

> On Mon, Feb 14, 2011 at 1:51 PM, Martin von Zweigbergk
> <martin.von.zweigbergk@gmail.com> 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].
 
> 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...

> But I wonder if it is possible to write a function shared by
> git-pull.sh and git-rebase.sh that computes the branch forking points,
> the number of arguments could detect if it has the old-remote-hash or
> not.

Makes sense. I will have a look at it.

> I think the delay could be much shorter if the computation was not in
> shell, but in C. Or maybe change the algorithm. So I don't think a
> configuration item is the answer here.

It would definitely be nice if we can make it fast enough so we don't
have to make it configurable.


[1] http://thread.gmane.org/gmane.comp.version-control.git/165758