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

5 messages from 2009-06-16 to 2009-06-16. Participants: Santi Béjar, Jeff King, Junio C Hamano.
Thread: https://gitlist.dev/t/19827

## Santi Béjar, 2009-06-16 11:08

Subject: branch.<branch>.merge and --format='%(upstream)'
Message-ID: <adf1fd3d0906160408s668f7a3fj5725cc4e98b317fc@mail.gmail.com>
URL: https://gitlist.dev/e/adf1fd3d0906160408s668f7a3fj5725cc4e98b317fc%40mail.gmail.com

```
Hi,

  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.

$ git clone git.git
$ cd git
$ git config branch.master.merge
refs/heads/master
$ git for-each-ref --format='%(upstream)' refs/heads/master
refs/remotes/origin/master
$ git config branch.master.merge master
$ git config branch.master.merge
master
$ git for-each-ref --format='%(upstream)' refs/heads/master

$

Best regards,
Santi

```

## Jeff King, 2009-06-16 12:23

Subject: Re: branch.<branch>.merge and --format='%(upstream)'
Message-ID: <20090616122312.GB5227@coredump.intra.peff.net>
URL: https://gitlist.dev/e/20090616122312.GB5227%40coredump.intra.peff.net
In-Reply-To: <adf1fd3d0906160408s668f7a3fj5725cc4e98b317fc@mail.gmail.com>

```
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.

I'm not sure of the impliciations of allowing non-qualified refs in that
config. Will we detect and warn about ambiguities? Does it actually work
with non-branches?

-Peff

```

## Santi Béjar, 2009-06-16 14:07

Subject: Re: branch.<branch>.merge and --format='%(upstream)'
Message-ID: <adf1fd3d0906160707m713d9fe0l966d14c0e0af9127@mail.gmail.com>
URL: https://gitlist.dev/e/adf1fd3d0906160707m713d9fe0l966d14c0e0af9127%40mail.gmail.com
In-Reply-To: <20090616122312.GB5227@coredump.intra.peff.net>

```
2009/6/16 Jeff King <peff@peff.net>:
> 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

```

## Junio C Hamano, 2009-06-16 15:46

Subject: Re: branch.<branch>.merge and --format='%(upstream)'
Message-ID: <7v7hzcdvvr.fsf@alter.siamese.dyndns.org>
URL: https://gitlist.dev/e/7v7hzcdvvr.fsf%40alter.siamese.dyndns.org
In-Reply-To: <20090616122312.GB5227@coredump.intra.peff.net>

```
Jeff King <peff@peff.net> writes:

> 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.

It wasn't.  Some places may accept them gracefully by either being extra
nice or by accident.

```

## Santi Béjar, 2009-06-16 22:34

Subject: Re: branch.<branch>.merge and --format='%(upstream)'
Message-ID: <1245191647-21353-1-git-send-email-santi@agolina.net>
URL: https://gitlist.dev/e/1245191647-21353-1-git-send-email-santi%40agolina.net
In-Reply-To: <7v7hzcdvvr.fsf@alter.siamese.dyndns.org>

```

2009/6/16 Junio C Hamano <gitster@pobox.com>
>
> Jeff King <peff@peff.net> writes:
>
> > 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.
>
> It wasn't.  Some places may accept them gracefully by either being extra
> nice or by accident.

And what about the comments in my reply. And in the branch.<name>.merge
docs says: The value is handled like the remote part of a refspec.

In fact I found it trying to implement a patch to get the local tracking
for a given remote and branch. But it only works if you spell the branch with
its full form:

$ git remote tracking origin master # does not work
$ git remote tracking origin refs/heads/master # does work
refs/remotes/origin/master

so I thought it would be better to resolve the %(upstream) first.

So if you know how to resolve this and or the %(upstream) issue, please tell me.

Anyway, here you have the WIP patch to get the tracking branch, I'm not sure
about the UI (or the script interface?), it is also a RFC.

---8<----
Subject: [RFC/PATCH]: Output tracking branch from remote and branch
---

Hi,

  as said above it is a RFC, specially for the UI, and also can anyone help
me with the:

$ git remote tracking origin master # does not work

case?

Thanks,
Santi

P.D: This case will be used in the "git pull --rebase remote branch" case.

 builtin-remote.c |   34 ++++++++++++++++++++++++++++++++++
 1 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/builtin-remote.c b/builtin-remote.c
index 709f8a6..03bcc27 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -665,6 +665,38 @@ static int remove_branches(struct string_list *branches)
 	return result;
 }
 
+static int tracking(int argc, const char **argv)
+{
+	struct option options[] = {
+		OPT_END()
+	};
+	struct remote *remote;
+	static const char **refs = NULL;
+	int ref_nr = 0;
+	int i = 0;
+	struct refspec *refspec;
+
+	if (argc < 3)
+		usage_with_options(builtin_remote_usage, options);
+	remote = remote_get(argv[1]);
+	if (!remote)
+		die("No such remote: %s", argv[1]);
+	refs = xcalloc(argc + 1, sizeof(const char *));
+	for (i = 2; i < argc; i++) {
+		refs[ref_nr++] = argv[i];
+	}
+	refs[ref_nr] = NULL;
+	memset(&refspec, 0, sizeof(*refspec));
+	refspec = parse_fetch_refspec(ref_nr, refs);
+	for (i = 0; i < ref_nr ; i++) {
+		if (!remote_find_tracking(remote, &refspec[i]))
+			printf("%s\n", refspec[i].dst);
+		else
+			return 1;
+	}
+	return 0;
+}
+
 static int rm(int argc, const char **argv)
 {
 	struct option options[] = {
@@ -1348,6 +1380,8 @@ int cmd_remote(int argc, const char **argv, const char *prefix)
 		result = show_all();
 	else if (!strcmp(argv[0], "add"))
 		result = add(argc, argv);
+	else if (!strcmp(argv[0], "tracking"))
+		result = tracking(argc, argv);
 	else if (!strcmp(argv[0], "rename"))
 		result = mv(argc, argv);
 	else if (!strcmp(argv[0], "rm"))
-- 
1.6.3.2.406.gd6a466

```