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