{"thread":{"id":"31756","subject":"git fetch documentation problem or bug","startedAt":"2012-10-08T18:59:04Z","lastAt":"2012-10-21T19:30:38Z","messageCount":7,"participants":["Angelo Borsotti","Junio C Hamano","Nguyen Thai Ngoc Duy","Drew Northup"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"200776","messageId":"CAB9Jk9Ac06sfFMGizRq6Ztqd2tKS7BBqGOC891=z4615J3f4hA@mail.gmail.com","threadId":"31756","inReplyTo":null,"subject":"git fetch documentation problem or bug","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-08T18:59:04Z","receivedAt":"2012-10-08T18:59:04Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hello,\n\ngit fetch does not create the remote refs in\nthe current (local)\nrepository, as shown by the following script:\n\ngit init remote\ngit clone remote local\n\n# populate the remote repository with a commit\ncd remote\ntouch f1\ngit add f1\ngit commit -m A\n\ncd ../local\ngit fetch origin master\ngit branch -avv\n\nNo ref is created.\n\nHowever, if a git fetch origin is executed, the refs are properly created:\n\ngit fetch origin\n * [new branch] master -> origin/master\n remotes/origin/master 8a9186d A\n\nI have not seen any clue in the documentation that tells the user\nabout this difference. The user may (naively) think that git fetch\norigin downloads all branches, while git fetch origin \ndownloads only , but it is not so.\nI am wandering if this is a documentation problem or a bug.\n\n-Angelo\n"},{"id":"200777","messageId":"7vfw5olqp9.fsf@alter.siamese.dyndns.org","threadId":"31756","inReplyTo":"CAB9Jk9Ac06sfFMGizRq6Ztqd2tKS7BBqGOC891=z4615J3f4hA@mail.gmail.com","subject":"Re: git fetch documentation problem or bug","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-08T19:16:34Z","receivedAt":"2012-10-08T19:16:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Angelo Borsotti writes:\n\n> git fetch does not create the remote refs in\n> the current (local)\n> repository...\n> However, if a git fetch origin is executed, the refs are properly created:\n\nWorking as designed and documented.\n\n $ git fetch origin master\n\nis giving the refspec \"master\" from the command line which is a\nshort-hand for \"refs/heads/master\".\n\nWhen you run\n\n $ git fetch origin\n\nconfigured refspec is looked up from your config (because you didn't\ngive any from the command line). The default refspec in your config\nis likely to be \"refs/heads/*:refs/remotes/origin/*\".\n\nThe former, \"refs/heads/master\" refspec, tells Git not to update the\nremote tracking branch. The latter has colon and right-hand-side of\nthe colon tells Git what to update with what was fetched.\n\nIt would hlep to read up on refspec by running \"git fetch --help\"\nand looking for a string \"colon\".\n"},{"id":"200778","messageId":"7vbogclqm6.fsf@alter.siamese.dyndns.org","threadId":"31756","inReplyTo":"7vfw5olqp9.fsf@alter.siamese.dyndns.org","subject":"Re: git fetch documentation problem or bug","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-08T19:18:25Z","receivedAt":"2012-10-08T19:18:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Angelo Borsotti writes:\n>\n>> git fetch does not create the remote refs in\n>> the current (local)\n>> repository...\n>> However, if a git fetch origin is executed, the refs are properly created:\n>\n> Working as designed and documented.\n>\n> $ git fetch origin master\n>\n> is giving the refspec \"master\" from the command line which is a\n> short-hand for \"refs/heads/master\".\n>\n> When you run\n>\n> $ git fetch origin\n>\n> configured refspec is looked up from your config (because you didn't\n> give any from the command line). The default refspec in your config\n> is likely to be \"refs/heads/*:refs/remotes/origin/*\".\n>\n> The former, \"refs/heads/master\" refspec, tells Git not to update the\n> remote tracking branch. The latter has colon and right-hand-side of\n> the colon tells Git what to update with what was fetched.\n>\n> It would hlep to read up on refspec by running \"git fetch --help\"\n> and looking for a string \"colon\".\n\nAddendum. Your claim\n\n>> git fetch does not create the remote refs in\n>> the current (local)\n>> repository...\n\nis incorrect. The behaviour depends on what you give.\n\nIn other words, you can do this from the command line if you want\nto do the update.\n\n $ git fetch origin master:refs/remotes/origin/master\n"},{"id":"200797","messageId":"7vpq4silou.fsf@alter.siamese.dyndns.org","threadId":"31756","inReplyTo":"7vbogclqm6.fsf@alter.siamese.dyndns.org","subject":"Re: git fetch documentation problem or bug","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-08T23:33:05Z","receivedAt":"2012-10-08T23:33:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> In other words, you can do this from the command line if you want\n> to do the update.\n>\n> $ git fetch origin master:refs/remotes/origin/master\n\nNow having said all that, we should probably revisit this and\npossibly other issues and for the ones we can reach concensus, start\ncoding after 1.8.0 final.\n\nA good place to start may be $gmane/167149, where I listed (among\nother things that turned out to be undesirable, which are omitted in\nthis copy):\n\n * \"git branch --set-upstream \" should not be about setting the\n upstream of to the current branch.\n\n This has happened during 1.8.0 cycle [CMN].\n\n * \"git push\" default semantics will be \"upstream\" (renamed from\n \"tracking\"), not \"matching\".\n\n 1.8.0 has the first step toward this [MM].\n\n * \"git merge\" without \"what to merge\" default to @{upstream}\n\n This is not acceptable for the default, but the users can ask for\n it with merge.defaultToUpstream since 1.7.5 era [JC]\n\n * Unify pathspec semantics\n\n This has happened and commands that used to take only path prefix\n style pathspecs now take globs as well [ND]\n\n * \"git fetch $from $branch...\" to update tracking branches\n\n This is the topic in this thread.\n\nI personally do not think the downside of breaking backward\ncompatibility is too bad. If we do this only when we already are\nconfigured to keep remote tracking branch for branch $branch from\nremote $from (it has to be given as a nickname, not URL that happens\nto have an entry in the configuration), then a promiscuous fetch\nthat grabs from a URL (or a nickname that is configured not to keep\ntracking branches) will not change any behaviour, and when you want\nto keep your remote tracking branch intact while doing one-shot\nfetch for whatever reason, you can say \"git fetch $from $branch:\" to\nexplicitly decline copying.\n"},{"id":"200800","messageId":"CACsJy8DOcfm1e9BnEjVCzs9u-QaG-jj8n6ehb6G_9dJqfyD7tA@mail.gmail.com","threadId":"31756","inReplyTo":"7vpq4silou.fsf@alter.siamese.dyndns.org","subject":"Re: git fetch documentation problem or bug","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-10-09T01:57:16Z","receivedAt":"2012-10-09T01:57:16Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Oct 9, 2012 at 6:33 AM, Junio C Hamano wrote:\n> * Unify pathspec semantics\n>\n> This has happened and commands that used to take only path prefix\n> style pathspecs now take globs as well [ND]\n\nI've been thinking about it lately and will probably restart soon with\na different approach. Still need to think about git-rm and git-mv as\nthey also accept directories (i.e. not exactly pathspec by\ndefinition).\n-- \nDuy\n"},{"id":"201628","messageId":"CAM9Z-nnKTq0C9wPA=JKZ3qzTmL3NVisfy=rbjjq1yKEVrN53FQ@mail.gmail.com","threadId":"31756","inReplyTo":"7vpq4silou.fsf@alter.siamese.dyndns.org","subject":"Re: git fetch documentation problem or bug","fromName":"Drew Northup","fromEmail":"n1xim.email@gmail.com","sentAt":"2012-10-21T12:15:41Z","receivedAt":"2012-10-21T12:15:41Z","isPatch":false,"sender":{"key":"n1xim.email@gmail.com","avatar":null},"body":"On Mon, Oct 8, 2012 at 7:33 PM, Junio C Hamano wrote:\n> Junio C Hamano writes:\n>\n>> In other words, you can do this from the command line if you want\n>> to do the update.\n>>\n>> $ git fetch origin master:refs/remotes/origin/master\n>\n> Now having said all that, we should probably revisit this and\n> possibly other issues and for the ones we can reach concensus, start\n> coding after 1.8.0 final.\n\n> * \"git fetch $from $branch...\" to update tracking branches\n>\n> This is the topic in this thread.\n>\n> I personally do not think the downside of breaking backward\n> compatibility is too bad. If we do this only when we already are\n> configured to keep remote tracking branch for branch $branch from\n> remote $from (it has to be given as a nickname, not URL that happens\n> to have an entry in the configuration), then a promiscuous fetch\n> that grabs from a URL (or a nickname that is configured not to keep\n> tracking branches) will not change any behaviour, and when you want\n> to keep your remote tracking branch intact while doing one-shot\n> fetch for whatever reason, you can say \"git fetch $from $branch:\" to\n> explicitly decline copying.\n\nHow are we supposed to remember those are different?\n\n\"git fetch $from $branch...\"\nVS\n\"git fetch $from $branch:\"\n\nI strongly prefer EXPLICITLY setting tracking than expecting some\nextreme syntactic nuance to quietly do it for me now and confuse the\nheck out of me later.\n\n-- \n-Drew Northup\n--------------------------------------------------------------\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"201646","messageId":"7vk3ujfwrl.fsf@alter.siamese.dyndns.org","threadId":"31756","inReplyTo":"CAM9Z-nnKTq0C9wPA=JKZ3qzTmL3NVisfy=rbjjq1yKEVrN53FQ@mail.gmail.com","subject":"Re: git fetch documentation problem or bug","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-21T19:30:38Z","receivedAt":"2012-10-21T19:30:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Drew Northup writes:\n\n> On Mon, Oct 8, 2012 at 7:33 PM, Junio C Hamano wrote:\n>> Junio C Hamano writes:\n>>\n>> I personally do not think the downside of breaking backward\n>> compatibility is too bad. If we do this only when we already are\n>> configured to keep remote tracking branch for branch $branch from\n>> remote $from (it has to be given as a nickname, not URL that happens\n>> to have an entry in the configuration), then a promiscuous fetch\n>> that grabs from a URL (or a nickname that is configured not to keep\n>> tracking branches) will not change any behaviour, and when you want\n>> to keep your remote tracking branch intact while doing one-shot\n>> fetch for whatever reason, you can say \"git fetch $from $branch:\" to\n>> explicitly decline copying.\n>\n> How are we supposed to remember those are different?\n>\n> \"git fetch $from $branch...\"\n> VS\n> \"git fetch $from $branch:\"\n\nI do not know what you meant by the three dots, but you are supposed\nto know what you meant by $branch... whatever it is. It is what you\nwrote, not I did ;-)\n\nLet me clarify what is in the message you are responding to.\n\n\tgit fetch $from $branch\n\n(no colon in $branch part anywhere) traditionally meant a short-hand\nof saying\n\n\tgit fetch $from $branch:\n\nI.e. \"fetch $branch and store in FETCH_HEAD but not anywhere else\".\n\nThe hypothesized change is to make it a short-hand of saying\n\n\tgit fetch $from $branch:refs/remotes/$from/$branch\n\nwhen \"git fetch $from\" is already configured to store the result\nthere. \n\nWithout [remote \"$from\"] fetch = refs/heads/*:refs/remotes/$from/*\nconfigured, it will still mean \"git fetch $from $branch:\".\n\nAnd for the record, I am *not* enthused about such a change. I am\nonly saying that, seeing that many new people seem to wish the\ncommand behaved that way, such a change would not hurt existing\nusers too much. Switching the meaning of shorthand (i.e. a piece of\nrefspec that does not have any colon) from \"just fetch but do not\nstore\" from \"fetch and store in the remote tracking ref if it is\nconfigured to do so without command override\" is still a backward\nincompatible change.\n\n> I strongly prefer EXPLICITLY setting tracking than expecting some\n> extreme syntactic nuance to quietly do it for me now and confuse the\n> heck out of me later.\n\nThis is not about your preference. This is about what happens when\nyou say something on the command line to override your explicit\nsetting you have in $GIT_DIR/config\n\n\t[remote \"$from\"] fetch = ...\n"}]}