Re: [PATCH] branch: Forbid to create local branches with confusing names

[Junio C Hamano <gitster@pobox.com>]

Ingo Rohloff <ingo.rohloff@lauterbach.com> writes:

> On Thu, 07 Nov 2019 15:05:49 +0900
> Junio C Hamano <gitster@pobox.com> wrote:
>> Ingo Rohloff <ingo.rohloff@lauterbach.com> writes:
>> 
>> > ...
>> > This patch forbids to create local branches, with names which start
>> > with any of
>> >
>> >   refs/
>> >   heads/
>> >   remotes/
>> >   tags/  
>> 
>> Is there a reason why notes/ hierarchy is excluded?  What about
>> pull/?  Are we dealing with an unbounded set?  Should this list be
>> somehow end-user configurable so that say Gerrit users can add for/
>> and changes/ to the "forbidden" set?
>
> I think I did not explain the intention that well.
> What I basically want to avoid is a situation in which there is
> no way at all to refer unambiguously to a particular reference.

Hmph, I thought this was a solved problem, but maybe I am still
misunderstanding you.

When you have a possibly ambigous branch whose name is $X, whether
$X begins with one of the strings you listed above or not, you can
always

 - refer to the commit at the tip of that branch by saying
   refs/heads/$X (e.g. "git show refs/heads/$X") and that always
   refers to the commit, even if there are other branches and tags
   that may begin with refs/ or refs/heads/.  You would of course
   get a warning about possible ambiguity because saying just $X
   (e.g. "git show $X") may not refer to refs/heads/$X when you have
   other refs that make $X ambiguous.

 - refer to the branch by saying $X (and not refs/heads/$X).

The thing to know is when you are naming a branch and when you are
naming a commit.

 - "git branch -d $X" is referring to the branch itself and removes
   refs/heads/$X.  

 - "git branch new <start-point>" uses <start-point> to specify the
   commit to begin the 'new' branch at, and does not necessarily
   take a branch name, so you should say refs/heads/$X.  You may not
   be able to rely on lazy-man's short-hands, like "git checkout -t
   origin/master" that DWIMs what you did not say, as you have to
   say refs/heads/$X that is *not* in the <remote-nick>/<branch>
   form (you can still do so with "git checkout -b master
   refs/heads/$X" followed by necessary configuration updates), but
   that is a price to pay for using ambiguous names.

And for those who do not want to pay for using ambiguous names, we
issue warnings when resolving refnames.