On Monday 13 April 2009 12:31:31 Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > I hope this helps a little bit with Mark's confusion. But while writing > > it, I really think it would be a simpler rule to say "if it's in > > refs/heads/, then it's a branch" (which is similar to what Mark > > suggested earlier). > > > > So "git checkout refs/heads/master" would be identical to "git checkout > > master". That would require a code change, though. > > Sorry, but I do not get the logic behind such a change. > I think the question being posed is: Would unifying branch names across all git commands (i.e., always accepting refs/heads/master as naming branch master, and accepting master when that is unambiguous) sufficiently benefit new users trying to learn git that it would be worth the change? The fact that refs/heads/master will be interpreted as branch or non-branch, and possibly as refs/heads/refs/heads/master, being a different branch, across different git commands is certainly not "intuitively obvious" to new users. In this vein, I suggest that $ git checkout --detach master as a way to get a detached HEAD on branch master is more understandable than $ git checkout refs/heads/master 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