John Keeping <john@xxxxxxxxxxxxx> writes: > 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... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html