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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 18, 2014, 19:51 UTC
Message-ID: <xmqqtxbwdwt2.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20140218193520.GB1048@serenity.lan>

John Keeping <john@keeping.me.uk> writes:

Show 5 quoted lines

> 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".

Not quite, I am afraid. Branch names used for "git branch <name>" and "git checkout <name>" are like the Lvalue of an assignment, as opposed to extended SHA-1 expressions to express any commit (e.g. 'master^0', 'refs/heads/master', or 'master') that correspond to the Rvalues used in an expression. Because "git checkout" can take a branch name or an arbitrary commit object name, there needs a way for the users to disambiguate.

Saying that "git checkout refs/heads/name" must be equivalent to "git checkout name" is like arguing that assignment "value+0 = x" should be valid because "value+0" is a valid value.

For the first parameter to "git branch", there is no ambiguity---it must be the name of a branch and cannot be an arbitrary commit object name, so special casing "git branch refs/heads/master" to mean "git branch master" may not be too bad. But then we need to either start rejecting "git branch refs/tags/v1.0" or keep allowing it to create a ref refs/heads/refs/tags/v1.0 to denote the branch of that exact name given---neither of which is more consistent, so...