Re: error: src refspec refs/heads/master matches more than one.
- From
David Kastrup <dak@gnu.org>
- Date
- Feb 18, 2014, 19:37 UTC
- Message-ID
- <871tz0rz3z.fsf@fencepost.gnu.org>
- In-Reply-To
- <xmqqha7wfdld.fsf@gitster.dls.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
Show 18 quoted lines
> 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.
-- David Kastrup