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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 18, 2014, 21:47 UTC
Message-ID: <xmqqlhx8ccu2.fsf@gitster.dls.corp.google.com>
In-Reply-To: <871tz0rz3z.fsf@fencepost.gnu.org>

David Kastrup <dak@gnu.org> writes:

Show 29 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Duy Nguyen <pclouds@gmail.com> writes:
>>
>>> +	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.
>>
>> 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.
>
> Just for the record: after seeing the respective arguments, I consider
> it the sanest way.
>
> It's conceivable to give a configuration option for augmenting the set
> of reserved prefixes.  That would allow to adapt the arbitrariness to
> match the policies or ref name choices of a particular project while
> keeping the set of references addressed by the standard git commands in
> check automagically.

I am inclined to say that we should start by just giving a warning whenever "git branch", "git checkout -b", etc. tries to create a branch whose name begins with "refs/" and other potentially ambiguous ones that match ref_rev_parse_rules[]. I personally do not think people name their branch with a name that begins with "refs/" on purpose; I am not sure about other ones, like "heads" or "tags". Personally I think it also is unlikely to want to have these words immediately followed by a slash in the branch name, so it may not even be necessary to give them any way to turn off the warning, which in turn would mean we can promote that warning to an die() that can be overridable with "--force", but by going that "first warn and see if people are annoyed" route, we would hopefully find out soon enough that there may be some people who do want to name their branches in a funny way ;-)