Re: error: src refspec refs/heads/master matches more than one.
- From
John Keeping <john@keeping.me.uk>
- Date
- Feb 18, 2014, 19:35 UTC
- Message-ID
- <20140218193520.GB1048@serenity.lan>
- In-Reply-To
- <xmqqha7wfdld.fsf@gitster.dls.corp.google.com>
On Tue, Feb 18, 2014 at 11:03:10AM -0800, Junio C Hamano wrote:
Show 30 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.
>
> 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.There's already the arbitrary set of prefixes in refs.c::prettify_refname() and refs.c::ref_rev_parse_rules(). I can see how a user might think that since "git log refs/heads/name" is equivalent to "git log master" then "git branch refs/heads/name" should be equivalent to "git branch name".
I don't think requiring "--force" for these branch names that overlap with these special namespaces is a big leap from supporting them for inspection commands. Although I'm not sure how sensible it is to examine every remote name to catch something like "git branch origin/master". Perhaps Duy's ambiguity check is the best thing for that case.