Re: [PATCH] builtin-branch - allow deleting a fully specified branch-name

[Mark Levedahl <mlevedahl@gmail.com>]

On Thursday 09 April 2009 23:18:01 you wrote:
>
> All other commands happen to take a branch name because that is just one
> case of extended SHA-1 expression to name an object.  In that context, a
> refname (which a branch name is a special case of) refers to the commit
> pointed by it.  E.g.
>
>         "git checkout HEAD~20 -- Makefile"
>         "git show refs/heads/foo"
>         "git show heads/foo"
>         "git show foo"

I think my underlying problem here is the porcelain's ability to use either a 
branch name or a ref name, in different contexts, leading to a sometimes 
inconsistent interface. Consider the following
   $ git checkout master
             checks out branch master
   $ git checkout refs/heads/master
             checks out commit pointed to by refs/heads/master on a detached 
HEAD

   $ git checkout -b refs/heads/master refs/heads/master
             creates a new branch, refname = refs/heads/refs/heads/master

The last command is the one that I find most curious. The exact same string 
has two entirely different meanings to the same command. I can explain why 
this happens, but I cannot explain why this is a good thing. 

A model I could explain without mental gymnastics would be "branch names are 
simply refnames without the leading refs/heads or refs/remotes, and a refname 
may be used wherever a branch name is requested. While branch names are 
potentially ambiguous, refnames never are."  Of course, this would mean that 
the refs/heads/refs/... namespace is illegal. I don't know of any other 
downside (except of course to someone using that namespace), and frankly I 
don't think the existence of the refs/heads/refs namespace is a good thing, 
given the potential for confusion.

Just a thought.

Mark