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

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

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.

---

index 65f5f9b..409c86c 100644
@@ -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;