# Suggestion: git fetch <remote> <branch> to update remote-tracking branch

3 messages from 2012-03-05 to 2012-03-06. Participants: Antony Male, Junio C Hamano, Jeff King.
Thread: https://gitlist.dev/t/29843

## Antony Male, 2012-03-05 16:45

Subject: Suggestion: git fetch <remote> <branch> to update remote-tracking branch
Message-ID: <4F54EDC1.80608@gmail.com>
URL: https://gitlist.dev/e/4F54EDC1.80608%40gmail.com

```
Hi all,

First off, this is a very tentative suggestion.  It would result in a 
slight change to established behaviour, which I'm well aware could be a 
Bad Thing(tm).  However, I was encouraged by a number of people on #git 
to make it anyway, so here goes.

The issue is this: the two-argument form of 'git fetch' (e.g. 'git fetch 
<remote> <branch>') fetches the named ref into FETCH_HEAD, but does not 
update the related remote-tracking branch.  While this is intuitive 
behaviour when <remote> is a URL, we see a lot of git beginners 
attempting to run 'git fetch origin branch' and being confused when 
origin/branch isn't updated.  Similarly, 'git pull origin master' will, 
in a simple case, fast-forward the local master but not origin/master.

My suggestion, therefore, is to modify the behaviour of 'git fetch' such 
that 'git fetch <remote> <branch>' will update both FETCH_HEAD and the 
relevant remote-tracking branch, when <remote> is the name of a 
configured remote and <branch> contains only the src part of the 
refspec.  The behaviour would not change when <remote> was a URL or 
path, or when a <src>:<dst> refspec was used.

Of course, it would be desirable to be able to replicate the existing 
behaviour.  Currently, I don't have any good suggestions, although there 
may be an existing trick I'm missing.  Possible suggestions might be 
'git fetch <remote> <branch>:FETCH_HEAD' or 'git fetch <remote> 
<branch>:', or maybe a new flag?

What do people think?

Many thanks for your time and consideration,
Antony Male

```

## Junio C Hamano, 2012-03-05 17:42

Subject: Re: Suggestion: git fetch <remote> <branch> to update remote-tracking branch
Message-ID: <7vmx7v0wrw.fsf@alter.siamese.dyndns.org>
URL: https://gitlist.dev/e/7vmx7v0wrw.fsf%40alter.siamese.dyndns.org
In-Reply-To: <4F54EDC1.80608@gmail.com>

```
Antony Male <antony.male@gmail.com> writes:

> What do people think?

I think this was discussed number of times here, and my vague
recollection of the conclusion last time is that it would be OK to
change the behaviour of single-shot fetch "fetch <remote> <branch>"
against a remote where there is already a default fetch refspec that
covers the <branch> so that such a fetch will update the remote
tracking branch that usually copies from <branch> (and only that
one).

We might need a proper deprecation and migration plan, though.  I
say "might" because offhand I don't know what the extent of damages
to existing users' habits will be if we didn't offer any.

```

## Jeff King, 2012-03-06 08:59

Subject: Re: Suggestion: git fetch <remote> <branch> to update remote-tracking branch
Message-ID: <20120306085919.GF21199@sigill.intra.peff.net>
URL: https://gitlist.dev/e/20120306085919.GF21199%40sigill.intra.peff.net
In-Reply-To: <7vmx7v0wrw.fsf@alter.siamese.dyndns.org>

```
On Mon, Mar 05, 2012 at 09:42:43AM -0800, Junio C Hamano wrote:

> > What do people think?
> 
> I think this was discussed number of times here, and my vague
> recollection of the conclusion last time is that it would be OK to
> change the behaviour of single-shot fetch "fetch <remote> <branch>"
> against a remote where there is already a default fetch refspec that
> covers the <branch> so that such a fetch will update the remote
> tracking branch that usually copies from <branch> (and only that
> one).
> 
> We might need a proper deprecation and migration plan, though.  I
> say "might" because offhand I don't know what the extent of damages
> to existing users' habits will be if we didn't offer any.

If you (or somebody else) wants to look into it, I've had this patch
hanging around in my repo since 2009, but it does cause a bunch of
failures in the test suite. I don't think I ever investigated whether
the test failures were bad assumptions in the tests, or signs of a real
problem. Those test failures may also give a clue about how unwitting
users would be affected.

---
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 65f5f9b..409c86c 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -156,6 +156,9 @@ static struct ref *get_ref_map(struct transport *transport,
 	const struct ref *remote_refs = transport_get_remote_refs(transport);
 
 	if (ref_count || tags == TAGS_SET) {
+		struct ref *tracking_refs = NULL;
+		struct ref **tracking_tail = &tracking_refs;
+
 		for (i = 0; i < ref_count; i++) {
 			get_fetch_map(remote_refs, &refs[i], &tail, 0);
 			if (refs[i].dst && refs[i].dst[0])
@@ -166,6 +169,12 @@ static struct ref *get_ref_map(struct transport *transport,
 			rm->merge = 1;
 		if (tags == TAGS_SET)
 			get_fetch_map(remote_refs, tag_refspec, &tail, 0);
+
+		for (i = 0; i < transport->remote->fetch_refspec_nr; i++)
+			get_fetch_map(ref_map, &transport->remote->fetch[i],
+					&tracking_tail, 0);
+		*tail = tracking_refs;
+		tail = tracking_tail;
 	} else {
 		/* Use the defaults */
 		struct remote *remote = transport->remote;

```