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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 20, 2014, 18:22 UTC
Message-ID: <xmqq61o97ig4.fsf@gitster.dls.corp.google.com>
In-Reply-To: <530581D5.4040507@alum.mit.edu>

Michael Haggerty <mhagger@alum.mit.edu> writes:

Show 16 quoted lines

> I wonder whether we could give a way to specify a reference in an
> unambiguous, canonical fashion like I expected, for example by using a
> leading slash: "/refs/heads/mybranch".  This could be a way for the user
> to ask for DWIMming to be turned off without having to resort to
> plumbing commands like update-ref.  This wouldn't necessarily solve the
> problem, but it would at least lead the new user to type
>
>     git branch /refs/heads/mybranch
>
> instead of the ambiguous command above, which Git could either accept or
> reject in good conscience rather than having to speculate about what the
> user *really* meant.  I think that supporting absolute reference names
> like this would also be useful for scripts, which otherwise probably
> often have subtle failure modes if the user has defined reference names
> that are ambiguous, modulo DWIM, with the reference that the script
> intended.

I do agree that things start to become confusing to the end users when we tell refnames and object names apart and behave differently, e.g. "git checkout master" vs "git checkout master^0" (this example uses a disambiguation syntax that is related to but different from what you brought up).

For the <name> in "git branch <name> [<commit>]" (but not <commit>), I do not see much value in allowing the users to say "refs/heads/" in the first place---all the local branch refs are to be created in refs/heads/ anyway and "git branch /refs/tags/bar" (if we were to allow your notation to name an absolute ref) will have to be checked and signaled as an error.

Even though there is no reason to forbid a ref to be named in such a way at the lowest machinery level (read: at the sha1_name.c layer) [*1*], I would say it would be better to at least warn users when they create such a ref with Porcelain commands like "branch", "checkout -b", etc., or even outright forbid.

In other contexts, however, it _might_ make sense, but I am somewhat skeptical. For example, if you have a branch 'foo' (whose ref being refs/heads/foo) and a branch 'refs/heads/foo' (whose ref being refs/heads/refs/heads/foo) at the same time, you need some way to clarify that you mean the former, and one way to do so may be

	git branch newfoo /refs/heads/foo

and removing the latter would be

	git branch -D /refs/heads/refs/heads/foo

perhaps. But this starts to sound like a workaround to a problem that the user ended up having such a strangely named branch in the first place, not a useful feature.

[Footnote]

*1* The way refs are used and the specific meanings given to some of
    the hierarchies under refs/ by the core-git Porcelain is not
    fundamental to the data model of Git.  Git the SCM by convention
    uses refs/heads/ for branches, and it is perfectly fine for Git
    the SCM to enforce its own policy like that to its end users and
    forbid creating and using any ref outside that hierarchy as a
    local branch (e.g. checking it out), but I'd prefer it if we can
    keep the lower level "a general filesystem to build SCM on top"
    layer as separate from such policy decision as possible.