{"thread":{"id":"29843","subject":"Suggestion: git fetch to update remote-tracking branch","startedAt":"2012-03-05T16:45:53Z","lastAt":"2012-03-06T08:59:19Z","messageCount":3,"participants":["Antony Male","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"186122","messageId":"4F54EDC1.80608@gmail.com","threadId":"29843","inReplyTo":null,"subject":"Suggestion: git fetch to update remote-tracking branch","fromName":"Antony Male","fromEmail":"antony.male@gmail.com","sentAt":"2012-03-05T16:45:53Z","receivedAt":"2012-03-05T16:45:53Z","isPatch":false,"sender":{"key":"antony.male@gmail.com","avatar":"https://gravatar.com/avatar/44ebc98c2d05837be689ed72514f8119844424a9cf099e5202be4190281982f1?d=mp&s=160"},"body":"Hi all,\n\nFirst off, this is a very tentative suggestion. It would result in a \nslight change to established behaviour, which I'm well aware could be a \nBad Thing(tm). However, I was encouraged by a number of people on #git \nto make it anyway, so here goes.\n\nThe issue is this: the two-argument form of 'git fetch' (e.g. 'git fetch \n ') fetches the named ref into FETCH_HEAD, but does not \nupdate the related remote-tracking branch. While this is intuitive \nbehaviour when is a URL, we see a lot of git beginners \nattempting to run 'git fetch origin branch' and being confused when \norigin/branch isn't updated. Similarly, 'git pull origin master' will, \nin a simple case, fast-forward the local master but not origin/master.\n\nMy suggestion, therefore, is to modify the behaviour of 'git fetch' such \nthat 'git fetch ' will update both FETCH_HEAD and the \nrelevant remote-tracking branch, when is the name of a \nconfigured remote and contains only the src part of the \nrefspec. The behaviour would not change when was a URL or \npath, or when a : refspec was used.\n\nOf course, it would be desirable to be able to replicate the existing \nbehaviour. Currently, I don't have any good suggestions, although there \nmay be an existing trick I'm missing. Possible suggestions might be \n'git fetch :FETCH_HEAD' or 'git fetch \n:', or maybe a new flag?\n\nWhat do people think?\n\nMany thanks for your time and consideration,\nAntony Male\n"},{"id":"186129","messageId":"7vmx7v0wrw.fsf@alter.siamese.dyndns.org","threadId":"29843","inReplyTo":"4F54EDC1.80608@gmail.com","subject":"Re: Suggestion: git fetch to update remote-tracking branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-05T17:42:43Z","receivedAt":"2012-03-05T17:42:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Antony Male writes:\n\n> What do people think?\n\nI think this was discussed number of times here, and my vague\nrecollection of the conclusion last time is that it would be OK to\nchange the behaviour of single-shot fetch \"fetch \"\nagainst a remote where there is already a default fetch refspec that\ncovers the so that such a fetch will update the remote\ntracking branch that usually copies from (and only that\none).\n\nWe might need a proper deprecation and migration plan, though. I\nsay \"might\" because offhand I don't know what the extent of damages\nto existing users' habits will be if we didn't offer any.\n"},{"id":"186186","messageId":"20120306085919.GF21199@sigill.intra.peff.net","threadId":"29843","inReplyTo":"7vmx7v0wrw.fsf@alter.siamese.dyndns.org","subject":"Re: Suggestion: git fetch to update remote-tracking branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-06T08:59:19Z","receivedAt":"2012-03-06T08:59:19Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 05, 2012 at 09:42:43AM -0800, Junio C Hamano wrote:\n\n> > What do people think?\n> \n> I think this was discussed number of times here, and my vague\n> recollection of the conclusion last time is that it would be OK to\n> change the behaviour of single-shot fetch \"fetch \"\n> against a remote where there is already a default fetch refspec that\n> covers the so that such a fetch will update the remote\n> tracking branch that usually copies from (and only that\n> one).\n> \n> We might need a proper deprecation and migration plan, though. I\n> say \"might\" because offhand I don't know what the extent of damages\n> to existing users' habits will be if we didn't offer any.\n\nIf you (or somebody else) wants to look into it, I've had this patch\nhanging around in my repo since 2009, but it does cause a bunch of\nfailures in the test suite. I don't think I ever investigated whether\nthe test failures were bad assumptions in the tests, or signs of a real\nproblem. Those test failures may also give a clue about how unwitting\nusers would be affected.\n\n---\ndiff --git a/builtin/fetch.c b/builtin/fetch.c\nindex 65f5f9b..409c86c 100644\n--- a/builtin/fetch.c\n+++ b/builtin/fetch.c\n@@ -156,6 +156,9 @@ static struct ref *get_ref_map(struct transport *transport,\n \tconst struct ref *remote_refs = transport_get_remote_refs(transport);\n \n \tif (ref_count || tags == TAGS_SET) {\n+\t\tstruct ref *tracking_refs = NULL;\n+\t\tstruct ref **tracking_tail = &tracking_refs;\n+\n \t\tfor (i = 0; i < ref_count; i++) {\n \t\t\tget_fetch_map(remote_refs, &refs[i], &tail, 0);\n \t\t\tif (refs[i].dst && refs[i].dst[0])\n@@ -166,6 +169,12 @@ static struct ref *get_ref_map(struct transport *transport,\n \t\t\trm->merge = 1;\n \t\tif (tags == TAGS_SET)\n \t\t\tget_fetch_map(remote_refs, tag_refspec, &tail, 0);\n+\n+\t\tfor (i = 0; i < transport->remote->fetch_refspec_nr; i++)\n+\t\t\tget_fetch_map(ref_map, &transport->remote->fetch[i],\n+\t\t\t\t\t&tracking_tail, 0);\n+\t\t*tail = tracking_refs;\n+\t\ttail = tracking_tail;\n \t} else {\n \t\t/* Use the defaults */\n \t\tstruct remote *remote = transport->remote;\n"}]}