{"thread":{"id":"35867","subject":"error: src refspec refs/heads/master matches more than one.","startedAt":"2014-02-14T11:31:36Z","lastAt":"2016-03-23T11:17:05Z","messageCount":21,"participants":["Josef Wolf","Andreas Schwab","Duy Nguyen","David Kastrup","Junio C Hamano","Ingo Rohloff","John Keeping","Michael Haggerty"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"234762","messageId":"20140214113136.GA17817@raven.inka.de","threadId":"35867","inReplyTo":null,"subject":"error: src refspec refs/heads/master matches more than one.","fromName":"Josef Wolf","fromEmail":"jw@raven.inka.de","sentAt":"2014-02-14T11:31:36Z","receivedAt":"2014-02-14T11:31:36Z","isPatch":false,"sender":{"key":"jw@raven.inka.de","avatar":null},"body":"Hello folks,\n\nafter some commits to my master branch, I tried to push to the bare upstream\nrepository and got this error message:\n\n error: src refspec refs/heads/master matches more than one.\n\nA quick check shows that there's indeed something wrong:\n\n jw@kiste:/git/scan$ git branch -a | grep master\n * master\n refs/heads/master\n remotes/origin/HEAD -> origin/master\n remotes/origin/master\n jw@kiste:/git/scan$ find .git -name master\n .git/refs/heads/master\n .git/logs/refs/remotes/origin/master\n .git/logs/refs/heads/master\n .git/logs/refs/heads/refs/heads/master\n jw@kiste:/git/scan$ find .git -name master\n .git/refs/heads\n .git/refs/heads/refs/heads\n .git/logs/refs/heads\n .git/logs/refs/heads/refs/heads\n jw@kiste:/git/scan$ find .git -name master\n\nNotice the refs/heads _within_ refs/heads!\n\nNow I wonder how I managed to get into this situation and what's the best way\nto recover?\n\nAny ideas?\n\nPS: this is git-1.8.1.4.\n\n-- \nJosef Wolf\njw@raven.inka.de\n"},{"id":"234765","messageId":"87a9dt981o.fsf@igel.home","threadId":"35867","inReplyTo":"20140214113136.GA17817@raven.inka.de","subject":"Re: error: src refspec refs/heads/master matches more than one.","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2014-02-14T12:45:55Z","receivedAt":"2014-02-14T12:45:55Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Josef Wolf writes:\n\n> Notice the refs/heads _within_ refs/heads!\n>\n> Now I wonder how I managed to get into this situation and what's the best way\n> to recover?\n\nProbably you did something like \"git branch refs/heads/master\". You can\nremove it again with \"git branch -d refs/heads/master\".\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"234766","messageId":"CACsJy8BevKQaRLYMMv7bTjf_ZAOnkrimws519OyhGZz6_Vr_-A@mail.gmail.com","threadId":"35867","inReplyTo":"87a9dt981o.fsf@igel.home","subject":"Re: error: src refspec refs/heads/master matches more than one.","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-02-14T12:59:18Z","receivedAt":"2014-02-14T12:59:18Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab wrote:\n> Josef Wolf writes:\n>\n>> Notice the refs/heads _within_ refs/heads!\n>>\n>> Now I wonder how I managed to get into this situation and what's the best way\n>> to recover?\n>\n> Probably you did something like \"git branch refs/heads/master\". You can\n> remove it again with \"git branch -d refs/heads/master\".\n\nAs a porcelain, \"git branch\" should prevent (or at least warn) users\nfrom creating such refs, I think.\n-- \nDuy\n"},{"id":"234769","messageId":"20140214151619.GB17817@raven.inka.de","threadId":"35867","inReplyTo":"CACsJy8BevKQaRLYMMv7bTjf_ZAOnkrimws519OyhGZz6_Vr_-A@mail.gmail.com","subject":"Re: error: src refspec refs/heads/master matches more than one.","fromName":"Josef Wolf","fromEmail":"jw@raven.inka.de","sentAt":"2014-02-14T15:16:19Z","receivedAt":"2014-02-14T15:16:19Z","isPatch":false,"sender":{"key":"jw@raven.inka.de","avatar":null},"body":"On Fri, Feb 14, 2014 at 07:59:18PM +0700, Duy Nguyen wrote:\n> On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab wrote:\n> > Josef Wolf writes:\n> >\n> >> Notice the refs/heads _within_ refs/heads!\n> > Probably you did something like \"git branch refs/heads/master\". You can\n> > remove it again with \"git branch -d refs/heads/master\".\n> As a porcelain, \"git branch\" should prevent (or at least warn) users\n> from creating such refs, I think.\n\nI don't think I did it the way Andreas thinks. This repository is maintained\nby a script, I don't create branches manually. The only command in this script\nthat uses \"heads\" is\n\n git symbolic-ref HEAD \"refs/heads/$new_branch\"\n\nto create new branches without any ancestry. And I double-checked that this\ncommand is _not_ resposible for those ghost branches.\n\nBTW: I see such ghost branches reappearing again and again, so it must be\n something systematic.\n\n-- \nJosef Wolf\njw@raven.inka.de\n"},{"id":"234771","messageId":"87ppmp3dxp.fsf@fencepost.gnu.org","threadId":"35867","inReplyTo":"20140214151619.GB17817@raven.inka.de","subject":"Re: error: src refspec refs/heads/master matches more than one.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-02-14T15:35:14Z","receivedAt":"2014-02-14T15:35:14Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Josef Wolf writes:\n\n> On Fri, Feb 14, 2014 at 07:59:18PM +0700, Duy Nguyen wrote:\n>> On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab wrote:\n>> > Josef Wolf writes:\n>> >\n>> >> Notice the refs/heads _within_ refs/heads!\n>> > Probably you did something like \"git branch refs/heads/master\". You can\n>> > remove it again with \"git branch -d refs/heads/master\".\n>> As a porcelain, \"git branch\" should prevent (or at least warn) users\n>> from creating such refs, I think.\n>\n> I don't think I did it the way Andreas thinks. This repository is maintained\n> by a script, I don't create branches manually. The only command in this script\n> that uses \"heads\" is\n>\n> git symbolic-ref HEAD \"refs/heads/$new_branch\"\n>\n> to create new branches without any ancestry. And I double-checked that this\n> command is _not_ resposible for those ghost branches.\n>\n> BTW: I see such ghost branches reappearing again and again, so it must be\n> something systematic.\n\nYou probably should check how $new_branch comes about. Also, once a\ndirectory refs/heads/refs/heads exists, \"refs/heads/$new_branch\" may\npossibly be resolved as a branch with the name refs/heads/$new_branch.\n\n-- \nDavid Kastrup\n"},{"id":"234775","messageId":"xmqqy51dirjs.fsf@gitster.dls.corp.google.com","threadId":"35867","inReplyTo":"CACsJy8BevKQaRLYMMv7bTjf_ZAOnkrimws519OyhGZz6_Vr_-A@mail.gmail.com","subject":"Re: error: src refspec refs/heads/master matches more than one.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-14T16:32:07Z","receivedAt":"2014-02-14T16:32:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab wrote:\n>> Josef Wolf writes:\n>>\n>>> Notice the refs/heads _within_ refs/heads!\n>>>\n>>> Now I wonder how I managed to get into this situation and what's the best way\n>>> to recover?\n>>\n>> Probably you did something like \"git branch refs/heads/master\". You can\n>> remove it again with \"git branch -d refs/heads/master\".\n>\n> As a porcelain, \"git branch\" should prevent (or at least warn) users\n> from creating such refs, I think.\n\n\"warn\", possibly, but I do not see a reason to *prevent*.\n\n A. You are not allowed to call your branch with a string that begins with\n 'refs/heads/'.\n B. Why?\n A. Because it will confuse you.\n B. I know what I am doing.\n A. ???\n"},{"id":"234778","messageId":"20140214165247.GC17817@raven.inka.de","threadId":"35867","inReplyTo":"87ppmp3dxp.fsf@fencepost.gnu.org","subject":"Re: error: src refspec refs/heads/master matches more than one.","fromName":"Josef Wolf","fromEmail":"jw@raven.inka.de","sentAt":"2014-02-14T16:52:48Z","receivedAt":"2014-02-14T16:52:48Z","isPatch":false,"sender":{"key":"jw@raven.inka.de","avatar":null},"body":"On Fri, Feb 14, 2014 at 04:35:14PM +0100, David Kastrup wrote:\n> Josef Wolf writes:\n> > The only command in this script that uses \"heads\" is\n> >\n> > git symbolic-ref HEAD \"refs/heads/$new_branch\"\n> >\n> You probably should check how $new_branch comes about.\n\nThis is the line of code where $new_branch is comes to live:\n\n my (undef, $new_branch, @new_path) = split (\"/\", $new_item);\n\nSo it is impossible that it might contain any slashes.\n\nIn any other situation, this script cares only about branches which start with\nthe string \"scan-file-XXXX\":\n\n sub local_branches { grep {m+^scan-file-+} &all_branches; }\n sub remote_branches { grep {m+^remotes/origin/scan-file-+} &all_branches; }\n\nThis is hard-coded, so I can't see any way for the user to inject \"refs/heads\"\n\n> Also, once a\n> directory refs/heads/refs/heads exists, \"refs/heads/$new_branch\" may\n> possibly be resolved as a branch with the name refs/heads/$new_branch.\n\nCan you elobarte on this? I don't get what you are trying to say.\n\nAs I already said, this happens on opensuse with git-1.8.1.4.\nI have not yet seen this problem on ubuntu with git-1.7.9.5.\n\n-- \nJosef Wolf\njw@raven.inka.de\n"},{"id":"234777","messageId":"87d2ip3ac9.fsf@fencepost.gnu.org","threadId":"35867","inReplyTo":"xmqqy51dirjs.fsf@gitster.dls.corp.google.com","subject":"Re: error: src refspec refs/heads/master matches more than one.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-02-14T16:52:54Z","receivedAt":"2014-02-14T16:52:54Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Junio C Hamano writes:\n\n> Duy Nguyen writes:\n>\n>> On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab wrote:\n>>> Josef Wolf writes:\n>>>\n>>>> Notice the refs/heads _within_ refs/heads!\n>>>>\n>>>> Now I wonder how I managed to get into this situation and what's the best way\n>>>> to recover?\n>>>\n>>> Probably you did something like \"git branch refs/heads/master\". You can\n>>> remove it again with \"git branch -d refs/heads/master\".\n>>\n>> As a porcelain, \"git branch\" should prevent (or at least warn) users\n>> from creating such refs, I think.\n>\n> \"warn\", possibly, but I do not see a reason to *prevent*.\n>\n> A. You are not allowed to call your branch with a string that begins with\n> 'refs/heads/'.\n> B. Why?\n> A. Because it will confuse you.\n> B. I know what I am doing.\n> A. ???\n\nA. But maybe Git will no longer know what you are doing. Its standard\nway of resolving references will mean that once a branch\nrefs/heads/wibble exists, referring to a branch wibble will become extra\nhard. For example, stuff like\n\npush origin HEAD:refs/heads/wibble\n\nwill maybe create or update a new branch wibble, or maybe it will just\npush to the existing branch refs/heads/wibble.\n\n-- \nDavid Kastrup\n"},{"id":"234787","messageId":"xmqqha81ik79.fsf@gitster.dls.corp.google.com","threadId":"35867","inReplyTo":"87d2ip3ac9.fsf@fencepost.gnu.org","subject":"Re: error: src refspec refs/heads/master matches more than one.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-14T19:10:50Z","receivedAt":"2014-02-14T19:10:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Kastrup writes:\n\n> Junio C Hamano writes:\n> ...\n>> A. Because it will confuse you.\n>> B. I know what I am doing.\n>> A. ???\n>\n> A. But maybe Git will no longer know what you are doing. Its standard\n> way of resolving references will mean that once a branch\n> refs/heads/wibble exists, referring to a branch wibble will become extra\n> hard. For example, stuff like\n>\n> push origin HEAD:refs/heads/wibble\n>\n> will maybe create or update a new branch wibble, or maybe it will just\n> push to the existing branch refs/heads/wibble.\n\nI suspect that is a bad example (do refs on _our_ side influence how\nRHS of the colon that names refs on the other side is interpreted),\nbut I think I know what you are trying to say. But Git never knows\nwhat you are doing---it just does what you tell it to, so it comes\nback to \"It will confuse you to the point that you would not be able\nto guess what Git will do matches your expectation\". Whenever I\ntell them that, a counterpoint B. makes is still \"I know what I am\ndoing.\", which is stubborn, rather obvious, and unfortunate.\n\nHow much of the namespace are we willing to carve out if we were to\ngo this route anyway? Things we use, i.e. refs/heads and refs/tags,\nwould be no-brainers, but do we also forbid refs/review, which we\nourselves do not use but some people may have in their repositories?\nAnything that begins with refs/? Anything that begins with refs/\nand has more than two slashes in it?\n"},{"id":"234820","messageId":"20140214225348.GD17817@raven.inka.de","threadId":"35867","inReplyTo":"xmqqy51dirjs.fsf@gitster.dls.corp.google.com","subject":"Re: error: src refspec refs/heads/master matches more than one.","fromName":"Josef Wolf","fromEmail":"jw@raven.inka.de","sentAt":"2014-02-14T22:53:48Z","receivedAt":"2014-02-14T22:53:48Z","isPatch":false,"sender":{"key":"jw@raven.inka.de","avatar":null},"body":"On Fri, Feb 14, 2014 at 08:32:07AM -0800, Junio C Hamano wrote:\n> A. You are not allowed to call your branch with a string that begins with\n> 'refs/heads/'.\n> B. Why?\n> A. Because it will confuse you.\n> B. I know what I am doing.\n> A. ???\n\nYour reply in\nhttp://git.661346.n2.nabble.com/1-8-0-git-checkout-refs-heads-foo-checks-out-branch-foo-td5999936.html\nsuggests that one should explicitly use the refs/heads prefix to to work\naround ambiguities in some situations.\n\nAre there any best-practices sugestions out there about when to use the\nrefs/heads prefix and when not? It looks like git delibaretly cuts off this\nprefix in some situations.\n\nI don't think my problem stems from something like \"git branch refs/heads/master\"\nAnyway, some clarifications about the usage of this prefix would be great!\n\n-- \nJosef Wolf\njw@raven.inka.de\n"},{"id":"234846","messageId":"20140215085355.GA15461@lanh","threadId":"35867","inReplyTo":"xmqqy51dirjs.fsf@gitster.dls.corp.google.com","subject":"Re: error: src refspec refs/heads/master matches more than one.","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-02-15T08:53:55Z","receivedAt":"2014-02-15T08:53:55Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Feb 14, 2014 at 08:32:07AM -0800, Junio C Hamano wrote:\n> Duy Nguyen writes:\n> \n> > On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab wrote:\n> >> Josef Wolf writes:\n> >>\n> >>> Notice the refs/heads _within_ refs/heads!\n> >>>\n> >>> Now I wonder how I managed to get into this situation and what's the best way\n> >>> to recover?\n> >>\n> >> Probably you did something like \"git branch refs/heads/master\". You can\n> >> remove it again with \"git branch -d refs/heads/master\".\n> >\n> > As a porcelain, \"git branch\" should prevent (or at least warn) users\n> > from creating such refs, I think.\n> \n> \"warn\", possibly, but I do not see a reason to *prevent*.\n> \n> A. You are not allowed to call your branch with a string that begins with\n> 'refs/heads/'.\n> B. Why?\n> A. Because it will confuse you.\n> B. I know what I am doing.\n> A. ???\n\nPrevent is a strong word. I meant we only do it if they force\nit. Something like this..\n\n-- 8< --\ndiff --git a/branch.c b/branch.c\nindex 723a36b..3f0540f 100644\n--- a/branch.c\n+++ b/branch.c\n@@ -251,6 +251,11 @@ void create_branch(const char *head,\n \t\t\tforcing = 1;\n \t}\n \n+\tif (!force && dwim_ref(name, strlen(name), sha1, &real_ref))\n+\t\tdie(_(\"creating ref refs/heads/%s makes %s ambiguous.\\n\"\n+\t\t \"Use -f to create it anyway.\"),\n+\t\t name, name);\n+\n \treal_ref = NULL;\n \tif (get_sha1(start_name, sha1)) {\n \t\tif (explicit_tracking) {\n-- 8< --\n"},{"id":"234932","messageId":"loom.20140217T152313-730@post.gmane.org","threadId":"35867","inReplyTo":"20140215085355.GA15461@lanh","subject":"Re: error: src refspec refs/heads/master matches more than one.","fromName":"Ingo Rohloff","fromEmail":"lundril@gmx.de","sentAt":"2014-02-17T14:25:53Z","receivedAt":"2014-02-17T14:25:53Z","isPatch":false,"sender":{"key":"lundril@gmx.de","avatar":null},"body":"Duy Nguyen gmail.com> writes:\n> Prevent is a strong word. I meant we only do it if they force\n> it. Something like this..\n> \n\nI would propose to make this even stronger:\nForbid to create any branches which start with any of:\n- \"refs/\"\n- \"heads/\"\n- \"remotes/\"\n- \"tags/\"\n\nas long as you do not use the \"force\" option.\n\nThe idea here is that you also will not get ambiguities later when you pull\nnew branches into your repository.\n\nso long\n Ingo\n"},{"id":"235001","messageId":"xmqqha7wfdld.fsf@gitster.dls.corp.google.com","threadId":"35867","inReplyTo":"20140215085355.GA15461@lanh","subject":"Re: error: src refspec refs/heads/master matches more than one.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-18T19:03:10Z","receivedAt":"2014-02-18T19:03:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> Prevent is a strong word. I meant we only do it if they force\n> it. Something like this..\n>\n> -- 8< --\n> diff --git a/branch.c b/branch.c\n> index 723a36b..3f0540f 100644\n> --- a/branch.c\n> +++ b/branch.c\n> @@ -251,6 +251,11 @@ void create_branch(const char *head,\n> \t\t\tforcing = 1;\n> \t}\n> \n> +\tif (!force && dwim_ref(name, strlen(name), sha1, &real_ref))\n> +\t\tdie(_(\"creating ref refs/heads/%s makes %s ambiguous.\\n\"\n> +\t\t \"Use -f to create it anyway.\"),\n> +\t\t name, name);\n\nDoes this check still allow you to create a branch \"refs/heads/next\"\nand then later create a branch \"next\"? The latter will introduce an\nambiguity without any prevention, even though the prevention would\ntrigger if the order in which these two branches are created is\nswapped--- the end result has ambiguity but the safety covers only\none avenue to the confusing situation.\n\nAnd the only way I can think of to avoid that kind of confusion is\nto forbid creation of a subset of possible names by reserving a set\nof known (but arbitrary) prefixes---which I am not sure is a good\nway to go. At least not yet.\n\nSo...\n"},{"id":"235006","messageId":"20140218193520.GB1048@serenity.lan","threadId":"35867","inReplyTo":"xmqqha7wfdld.fsf@gitster.dls.corp.google.com","subject":"Re: error: src refspec refs/heads/master matches more than one.","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2014-02-18T19:35:20Z","receivedAt":"2014-02-18T19:35:20Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Tue, Feb 18, 2014 at 11:03:10AM -0800, Junio C Hamano wrote:\n> Duy Nguyen writes:\n> \n> > Prevent is a strong word. I meant we only do it if they force\n> > it. Something like this..\n> >\n> > -- 8< --\n> > diff --git a/branch.c b/branch.c\n> > index 723a36b..3f0540f 100644\n> > --- a/branch.c\n> > +++ b/branch.c\n> > @@ -251,6 +251,11 @@ void create_branch(const char *head,\n> > \t\t\tforcing = 1;\n> > \t}\n> > \n> > +\tif (!force && dwim_ref(name, strlen(name), sha1, &real_ref))\n> > +\t\tdie(_(\"creating ref refs/heads/%s makes %s ambiguous.\\n\"\n> > +\t\t \"Use -f to create it anyway.\"),\n> > +\t\t name, name);\n> \n> Does this check still allow you to create a branch \"refs/heads/next\"\n> and then later create a branch \"next\"? The latter will introduce an\n> ambiguity without any prevention, even though the prevention would\n> trigger if the order in which these two branches are created is\n> swapped--- the end result has ambiguity but the safety covers only\n> one avenue to the confusing situation.\n> \n> And the only way I can think of to avoid that kind of confusion is\n> to forbid creation of a subset of possible names by reserving a set\n> of known (but arbitrary) prefixes---which I am not sure is a good\n> way to go. At least not yet.\n\nThere's already the arbitrary set of prefixes in\nrefs.c::prettify_refname() and refs.c::ref_rev_parse_rules(). I can see\nhow a user might think that since \"git log refs/heads/name\" is\nequivalent to \"git log master\" then \"git branch refs/heads/name\" should\nbe equivalent to \"git branch name\".\n\nI don't think requiring \"--force\" for these branch names that overlap\nwith these special namespaces is a big leap from supporting them for\ninspection commands. Although I'm not sure how sensible it is to\nexamine every remote name to catch something like \"git branch\norigin/master\". Perhaps Duy's ambiguity check is the best thing for\nthat case.\n"},{"id":"235008","messageId":"871tz0rz3z.fsf@fencepost.gnu.org","threadId":"35867","inReplyTo":"xmqqha7wfdld.fsf@gitster.dls.corp.google.com","subject":"Re: error: src refspec refs/heads/master matches more than one.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-02-18T19:37:36Z","receivedAt":"2014-02-18T19:37:36Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Junio C Hamano writes:\n\n> Duy Nguyen writes:\n>\n>> +\tif (!force && dwim_ref(name, strlen(name), sha1, &real_ref))\n>> +\t\tdie(_(\"creating ref refs/heads/%s makes %s ambiguous.\\n\"\n>> +\t\t \"Use -f to create it anyway.\"),\n>> +\t\t name, name);\n>\n> Does this check still allow you to create a branch \"refs/heads/next\"\n> and then later create a branch \"next\"? The latter will introduce an\n> ambiguity without any prevention, even though the prevention would\n> trigger if the order in which these two branches are created is\n> swapped--- the end result has ambiguity but the safety covers only one\n> avenue to the confusing situation.\n>\n> And the only way I can think of to avoid that kind of confusion is\n> to forbid creation of a subset of possible names by reserving a set\n> of known (but arbitrary) prefixes---which I am not sure is a good\n> way to go. At least not yet.\n\nJust for the record: after seeing the respective arguments, I consider\nit the sanest way.\n\nIt's conceivable to give a configuration option for augmenting the set\nof reserved prefixes. That would allow to adapt the arbitrariness to\nmatch the policies or ref name choices of a particular project while\nkeeping the set of references addressed by the standard git commands in\ncheck automagically.\n\n-- \nDavid Kastrup\n"},{"id":"235010","messageId":"xmqqtxbwdwt2.fsf@gitster.dls.corp.google.com","threadId":"35867","inReplyTo":"20140218193520.GB1048@serenity.lan","subject":"Re: error: src refspec refs/heads/master matches more than one.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-18T19:51:05Z","receivedAt":"2014-02-18T19:51:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping writes:\n\n> There's already the arbitrary set of prefixes in\n> refs.c::prettify_refname() and refs.c::ref_rev_parse_rules(). I can see\n> how a user might think that since \"git log refs/heads/name\" is\n> equivalent to \"git log master\" then \"git branch refs/heads/name\" should\n> be equivalent to \"git branch name\".\n\nNot quite, I am afraid. Branch names used for \"git branch \"\nand \"git checkout \" are like the Lvalue of an assignment, as\nopposed to extended SHA-1 expressions to express any commit\n(e.g. 'master^0', 'refs/heads/master', or 'master') that correspond\nto the Rvalues used in an expression. Because \"git checkout\" can\ntake a branch name or an arbitrary commit object name, there needs a\nway for the users to disambiguate.\n\nSaying that \"git checkout refs/heads/name\" must be equivalent to\n\"git checkout name\" is like arguing that assignment \"value+0 = x\"\nshould be valid because \"value+0\" is a valid value.\n\nFor the first parameter to \"git branch\", there is no ambiguity---it\nmust be the name of a branch and cannot be an arbitrary commit\nobject name, so special casing \"git branch refs/heads/master\" to\nmean \"git branch master\" may not be too bad. But then we need to\neither start rejecting \"git branch refs/tags/v1.0\" or keep allowing\nit to create a ref refs/heads/refs/tags/v1.0 to denote the branch of\nthat exact name given---neither of which is more consistent, so...\n"},{"id":"235012","messageId":"20140218200146.GC1048@serenity.lan","threadId":"35867","inReplyTo":"xmqqtxbwdwt2.fsf@gitster.dls.corp.google.com","subject":"Re: error: src refspec refs/heads/master matches more than one.","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2014-02-18T20:01:46Z","receivedAt":"2014-02-18T20:01:46Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Tue, Feb 18, 2014 at 11:51:05AM -0800, Junio C Hamano wrote:\n> John Keeping writes:\n> \n> > There's already the arbitrary set of prefixes in\n> > refs.c::prettify_refname() and refs.c::ref_rev_parse_rules(). I can see\n> > how a user might think that since \"git log refs/heads/name\" is\n> > equivalent to \"git log master\" then \"git branch refs/heads/name\" should\n> > be equivalent to \"git branch name\".\n> \n> Not quite, I am afraid. Branch names used for \"git branch \"\n> and \"git checkout \" are like the Lvalue of an assignment, as\n> opposed to extended SHA-1 expressions to express any commit\n> (e.g. 'master^0', 'refs/heads/master', or 'master') that correspond\n> to the Rvalues used in an expression. Because \"git checkout\" can\n> take a branch name or an arbitrary commit object name, there needs a\n> way for the users to disambiguate.\n> \n> Saying that \"git checkout refs/heads/name\" must be equivalent to\n> \"git checkout name\" is like arguing that assignment \"value+0 = x\"\n> should be valid because \"value+0\" is a valid value.\n\nThat isn't my argument. I agree that the \"create\" and \"view\" operations\nare distinct. The problem appears to be that not all users expect this\nand it caused them confusion because they are able to create refs like\nrefs/heads/refs/heads/master.\n\nI don't think we should apply the mapping, but I also do not think that\nusing a set of known (but arbitrary) constraints to prevent the creation\nof potentially confusing branch names is a particularly big leap from\napplying a similar set of rules in prettify_ref() and dwim_ref().\nEspecially if there's an escape hatch via '--force' or 'git update-ref'\nfor those who know what they're doing.\n"},{"id":"235026","messageId":"xmqqlhx8ccu2.fsf@gitster.dls.corp.google.com","threadId":"35867","inReplyTo":"871tz0rz3z.fsf@fencepost.gnu.org","subject":"Re: error: src refspec refs/heads/master matches more than one.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-18T21:47:49Z","receivedAt":"2014-02-18T21:47:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Kastrup writes:\n\n> Junio C Hamano writes:\n>\n>> Duy Nguyen writes:\n>>\n>>> +\tif (!force && dwim_ref(name, strlen(name), sha1, &real_ref))\n>>> +\t\tdie(_(\"creating ref refs/heads/%s makes %s ambiguous.\\n\"\n>>> +\t\t \"Use -f to create it anyway.\"),\n>>> +\t\t name, name);\n>>\n>> Does this check still allow you to create a branch \"refs/heads/next\"\n>> and then later create a branch \"next\"? The latter will introduce an\n>> ambiguity without any prevention, even though the prevention would\n>> trigger if the order in which these two branches are created is\n>> swapped--- the end result has ambiguity but the safety covers only one\n>> avenue to the confusing situation.\n>>\n>> And the only way I can think of to avoid that kind of confusion is\n>> to forbid creation of a subset of possible names by reserving a set\n>> of known (but arbitrary) prefixes---which I am not sure is a good\n>> way to go. At least not yet.\n>\n> Just for the record: after seeing the respective arguments, I consider\n> it the sanest way.\n>\n> It's conceivable to give a configuration option for augmenting the set\n> of reserved prefixes. That would allow to adapt the arbitrariness to\n> match the policies or ref name choices of a particular project while\n> keeping the set of references addressed by the standard git commands in\n> check automagically.\n\nI am inclined to say that we should start by just giving a warning\nwhenever \"git branch\", \"git checkout -b\", etc. tries to create a\nbranch whose name begins with \"refs/\" and other potentially\nambiguous ones that match ref_rev_parse_rules[]. I personally do\nnot think people name their branch with a name that begins with\n\"refs/\" on purpose; I am not sure about other ones, like \"heads\" or\n\"tags\". Personally I think it also is unlikely to want to have these\nwords immediately followed by a slash in the branch name, so it may\nnot even be necessary to give them any way to turn off the warning,\nwhich in turn would mean we can promote that warning to an die()\nthat can be overridable with \"--force\", but by going that \"first\nwarn and see if people are annoyed\" route, we would hopefully find\nout soon enough that there may be some people who do want to name\ntheir branches in a funny way ;-)\n"},{"id":"235088","messageId":"530581D5.4040507@alum.mit.edu","threadId":"35867","inReplyTo":"xmqqtxbwdwt2.fsf@gitster.dls.corp.google.com","subject":"Re: error: src refspec refs/heads/master matches more than one.","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2014-02-20T04:17:25Z","receivedAt":"2014-02-20T04:17:25Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 02/18/2014 08:51 PM, Junio C Hamano wrote:\n> John Keeping writes:\n> \n>> There's already the arbitrary set of prefixes in\n>> refs.c::prettify_refname() and refs.c::ref_rev_parse_rules(). I can see\n>> how a user might think that since \"git log refs/heads/name\" is\n>> equivalent to \"git log master\" then \"git branch refs/heads/name\" should\n>> be equivalent to \"git branch name\".\n> \n> Not quite, I am afraid. Branch names used for \"git branch \"\n> and \"git checkout \" are like the Lvalue of an assignment, as\n> opposed to extended SHA-1 expressions to express any commit\n> (e.g. 'master^0', 'refs/heads/master', or 'master') that correspond\n> to the Rvalues used in an expression. Because \"git checkout\" can\n> take a branch name or an arbitrary commit object name, there needs a\n> way for the users to disambiguate.\n> \n> Saying that \"git checkout refs/heads/name\" must be equivalent to\n> \"git checkout name\" is like arguing that assignment \"value+0 = x\"\n> should be valid because \"value+0\" is a valid value.\n\nYour logic is impeccable...and yet the user's logic is also quite\nreasonable. I fell into this trap when I started using Git, and so did\nmost (all?) of my colleagues.\n\nI think the problem is partly caused by the visual and semantic\nsimilarity between references and Unix pathnames. For pathnames, the\nfile that is called \"filename.txt\" in my current context has an\nunambiguous, canonical name that might be \"/home/mhagger/filename.txt\".\n My first mental model of Git references was that \"branch\" and\n\"refs/heads/branch\" are synonyms, and that the latter is somehow the\n\"unambiguous\" and \"canonical\" way to write it. I think this mental\nmodel is what led me to make the universal beginner's mistake\n\n git branch refs/heads/mybranch\n\nIt took me a while to figure out how to fix the situation, and the whole\nexperience was very frustrating.\n\nI wonder whether we could give a way to specify a reference in an\nunambiguous, canonical fashion like I expected, for example by using a\nleading slash: \"/refs/heads/mybranch\". This could be a way for the user\nto ask for DWIMming to be turned off without having to resort to\nplumbing commands like update-ref. This wouldn't necessarily solve the\nproblem, but it would at least lead the new user to type\n\n git branch /refs/heads/mybranch\n\ninstead of the ambiguous command above, which Git could either accept or\nreject in good conscience rather than having to speculate about what the\nuser *really* meant. I think that supporting absolute reference names\nlike this would also be useful for scripts, which otherwise probably\noften have subtle failure modes if the user has defined reference names\nthat are ambiguous, modulo DWIM, with the reference that the script\nintended.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"235101","messageId":"xmqq61o97ig4.fsf@gitster.dls.corp.google.com","threadId":"35867","inReplyTo":"530581D5.4040507@alum.mit.edu","subject":"Re: error: src refspec refs/heads/master matches more than one.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-20T18:22:19Z","receivedAt":"2014-02-20T18:22:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> I wonder whether we could give a way to specify a reference in an\n> unambiguous, canonical fashion like I expected, for example by using a\n> leading slash: \"/refs/heads/mybranch\". This could be a way for the user\n> to ask for DWIMming to be turned off without having to resort to\n> plumbing commands like update-ref. This wouldn't necessarily solve the\n> problem, but it would at least lead the new user to type\n>\n> git branch /refs/heads/mybranch\n>\n> instead of the ambiguous command above, which Git could either accept or\n> reject in good conscience rather than having to speculate about what the\n> user *really* meant. I think that supporting absolute reference names\n> like this would also be useful for scripts, which otherwise probably\n> often have subtle failure modes if the user has defined reference names\n> that are ambiguous, modulo DWIM, with the reference that the script\n> intended.\n\nI do agree that things start to become confusing to the end users\nwhen we tell refnames and object names apart and behave differently,\ne.g. \"git checkout master\" vs \"git checkout master^0\" (this example\nuses a disambiguation syntax that is related to but different from\nwhat you brought up).\n\nFor the in \"git branch []\" (but not ),\nI do not see much value in allowing the users to say \"refs/heads/\"\nin the first place---all the local branch refs are to be created in\nrefs/heads/ anyway and \"git branch /refs/tags/bar\" (if we were to\nallow your notation to name an absolute ref) will have to be checked\nand signaled as an error.\n\nEven though there is no reason to forbid a ref to be named in such a\nway at the lowest machinery level (read: at the sha1_name.c layer)\n[*1*], I would say it would be better to at least warn users when\nthey create such a ref with Porcelain commands like \"branch\",\n\"checkout -b\", etc., or even outright forbid.\n\nIn other contexts, however, it _might_ make sense, but I am somewhat\nskeptical. For example, if you have a branch 'foo' (whose ref being\nrefs/heads/foo) and a branch 'refs/heads/foo' (whose ref being\nrefs/heads/refs/heads/foo) at the same time, you need some way to\nclarify that you mean the former, and one way to do so may be\n\n\tgit branch newfoo /refs/heads/foo\n\nand removing the latter would be\n\n\tgit branch -D /refs/heads/refs/heads/foo\n\nperhaps. But this starts to sound like a workaround to a problem\nthat the user ended up having such a strangely named branch in the\nfirst place, not a useful feature.\n\n[Footnote]\n\n*1* The way refs are used and the specific meanings given to some of\n the hierarchies under refs/ by the core-git Porcelain is not\n fundamental to the data model of Git. Git the SCM by convention\n uses refs/heads/ for branches, and it is perfectly fine for Git\n the SCM to enforce its own policy like that to its end users and\n forbid creating and using any ref outside that hierarchy as a\n local branch (e.g. checking it out), but I'd prefer it if we can\n keep the lower level \"a general filesystem to build SCM on top\"\n layer as separate from such policy decision as possible.\n"},{"id":"281573","messageId":"CACsJy8BR-f0qLV9VC1YPMhdBu3hFMZqqrNq-6RPBmTu1iQ+7hg@mail.gmail.com","threadId":"35867","inReplyTo":"xmqqha7wfdld.fsf@gitster.dls.corp.google.com","subject":"Re: error: src refspec refs/heads/master matches more than one.","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-03-23T11:17:05Z","receivedAt":"2016-03-23T11:17:05Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"I'm digging this topic up from the ground because if it was fixed, I\nwould not have spent many confusing (and a little bit panicking)\nminutes wondering how the hell I managed to push to \"origin/master\"\nwhich I did not have push access to begin with, which turned out to be\nthe local branch, refs/heads/origin/master, not the remote branch\nrefs/remotes/origin/master.\n\nSummary until this point in the old thread, you can accidentally do\n\"git branch refs/heads/next\", which happily creates\nrefs/heads/refs/heads/next. If you also have refs/heads/next, things\ncan get confusing for commands that accepts both branch and non-branch\nrefs. There were some more discussion about unambiguously specifying\nfull ref in git-branch but it was getting nowhere.\n\nOn Wed, Feb 19, 2014 at 2:03 AM, Junio C Hamano wrote:\n> Duy Nguyen writes:\n>\n>> Prevent is a strong word. I meant we only do it if they force\n>> it. Something like this..\n>>\n>> -- 8< --\n>> diff --git a/branch.c b/branch.c\n>> index 723a36b..3f0540f 100644\n>> --- a/branch.c\n>> +++ b/branch.c\n>> @@ -251,6 +251,11 @@ void create_branch(const char *head,\n>> forcing = 1;\n>> }\n>>\n>> + if (!force && dwim_ref(name, strlen(name), sha1, &real_ref))\n>> + die(_(\"creating ref refs/heads/%s makes %s ambiguous.\\n\"\n>> + \"Use -f to create it anyway.\"),\n>> + name, name);\n>\n> Does this check still allow you to create a branch \"refs/heads/next\"\n> and then later create a branch \"next\"? The latter will introduce an\n> ambiguity without any prevention, even though the prevention would\n> trigger if the order in which these two branches are created is\n> swapped--- the end result has ambiguity but the safety covers only\n> one avenue to the confusing situation.\n\nIt could be fixed by checking all existing refs if any of them becomes\nambiguous after refs/heads/next comes to life. We can filter and check\nonly branch that shares the same base name (or starts with \"refs/\",\n\"heads/\", \"tags/\" or \"remotes/\"), so it's still expensive but not as\nmuch as checking all refs.\n\nEven with covering only one avenue, it would definitely help my case\n(refs/remotes/origin/master exists and refs/heads/origin/master asked\nto be created).\n\nAlso in my case, if refs/heads/origin/master already exists then I\nthink I should reject creating refs/remotes/origin/master, or warn\nloudly.\n\nSounds promising enough to start making patches?\n\n> And the only way I can think of to avoid that kind of confusion is\n> to forbid creation of a subset of possible names by reserving a set\n> of known (but arbitrary) prefixes---which I am not sure is a good\n> way to go. At least not yet.\n-- \nDuy\n"}]}