Re: branch.<branch>.merge and --format='%(upstream)'

From: Santi Béjar <santi@agolina.net>
Date: Jun 16, 2009, 14:07 UTC
Message-ID: <adf1fd3d0906160707m713d9fe0l966d14c0e0af9127@mail.gmail.com>
In-Reply-To: <20090616122312.GB5227@coredump.intra.peff.net>

2009/6/16 Jeff King <peff@peff.net>:

Show 16 quoted lines

> On Tue, Jun 16, 2009 at 01:08:02PM +0200, Santi Béjar wrote:
>
>>   I've noticed that having branch.<branch>.merge set with the branch
>> name, and not with the full ref, cause problems with
>> --format='%(upstream)'  and also with the "branch -av" and "git
>> status" upstream branch outputs. But git-fetch and git-pull works ok,
>> so it is a valid setting.
>
> Actually, it is broken in a lot of places. for-each-ref relies on the
> same code as "git status", "git checkout", etc, which will all fail to
> display tracking info. I believe the same code is also used for updating
> tracking branches on push. So I'm not sure if it was ever intended to be
> a valid setting.
>
> Fixing it would involve tweaks to remote_find_tracking, I think, but I
> haven't looked into it too closely.

It should be interpreted as "git pull branchname" does, or at least as close as possible.

Another non-working example is with:

remote.origin.fetch=+master:refs/remotes/origin/master branch.master.merge=refs/heads/master

so it looks like that both have to match for remote_find_tracking to work (and in this case "git fetch" also works ok).

I suppose that remote_find_tracking should DWIM: build the full ref prepending refs/ and heads/, as necessary.

>
> I'm not sure of the impliciations of allowing non-qualified refs in that
> config.

They are currently allowed (fetch/pull) since a long time, and it is not only this config, but also remote.<remote>.fetch (see above).

In b888d61 (Make fetch a builtin, 2007-09-10):

commit b888d61c8308027433df9c243fa551f42db1c76a
Author: Daniel Barkalow <barkalow@iabervon.org>
Date:   Tue Sep 11 05:03:25 2007

[...]

    This changes a few small bits of behavior:

    branch.<name>.merge is parsed as if it were the lhs of a fetch
    refspec, and does not have to exactly match the actual lhs of a
    refspec, so long as it is a valid abbreviation for the same ref.

[...]

> Will we detect and warn about ambiguities? Does it actually work
> with non-branches?

With tags yes, but full qualified.

Santi