Re: error: src refspec refs/heads/master matches more than one.

From: Duy Nguyen <pclouds@gmail.com>
Date: Mar 23, 2016, 11:17 UTC
Message-ID: <CACsJy8BR-f0qLV9VC1YPMhdBu3hFMZqqrNq-6RPBmTu1iQ+7hg@mail.gmail.com>
In-Reply-To: <xmqqha7wfdld.fsf@gitster.dls.corp.google.com>

I'm digging this topic up from the ground because if it was fixed, I would not have spent many confusing (and a little bit panicking) minutes wondering how the hell I managed to push to "origin/master" which I did not have push access to begin with, which turned out to be the local branch, refs/heads/origin/master, not the remote branch refs/remotes/origin/master.

Summary until this point in the old thread, you can accidentally do "git branch refs/heads/next", which happily creates refs/heads/refs/heads/next. If you also have refs/heads/next, things can get confusing for commands that accepts both branch and non-branch refs. There were some more discussion about unambiguously specifying full ref in git-branch but it was getting nowhere.

On Wed, Feb 19, 2014 at 2:03 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 25 quoted lines

> Duy Nguyen <pclouds@gmail.com> writes:
>
>> Prevent is a strong word. I meant we only do it if they force
>> it. Something like this..
>>
>> -- 8< --
>> diff --git a/branch.c b/branch.c
>> index 723a36b..3f0540f 100644
>> --- a/branch.c
>> +++ b/branch.c
>> @@ -251,6 +251,11 @@ void create_branch(const char *head,
>>                       forcing = 1;
>>       }
>>
>> +     if (!force && dwim_ref(name, strlen(name), sha1, &real_ref))
>> +             die(_("creating ref refs/heads/%s makes %s ambiguous.\n"
>> +                   "Use -f to create it anyway."),
>> +                 name, name);
>
> Does this check still allow you to create a branch "refs/heads/next"
> and then later create a branch "next"?  The latter will introduce an
> ambiguity without any prevention, even though the prevention would
> trigger if the order in which these two branches are created is
> swapped--- the end result has ambiguity but the safety covers only
> one avenue to the confusing situation.

It could be fixed by checking all existing refs if any of them becomes ambiguous after refs/heads/next comes to life. We can filter and check only branch that shares the same base name (or starts with "refs/", "heads/", "tags/" or "remotes/"), so it's still expensive but not as much as checking all refs.

Even with covering only one avenue, it would definitely help my case (refs/remotes/origin/master exists and refs/heads/origin/master asked to be created).

Also in my case, if refs/heads/origin/master already exists then I think I should reject creating refs/remotes/origin/master, or warn loudly.

Sounds promising enough to start making patches?

> And the only way I can think of to avoid that kind of confusion is
> to forbid creation of a subset of possible names by reserving a set
> of known (but arbitrary) prefixes---which I am not sure is a good
> way to go.  At least not yet.

-- 
Duy