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

From: Mark Levedahl <mlevedahl@gmail.com>
Date: Apr 11, 2009, 17:01 UTC
Message-ID: <200904111301.31250.mlevedahl@gmail.com>
In-Reply-To: <7vbpr519jq.fsf@gitster.siamese.dyndns.org>

On Thursday 09 April 2009 23:18:01 you wrote:

Show 10 quoted lines

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