Ingo Rohloff <ingo.rohloff@xxxxxxxxxxxxxx> writes: > On Thu, 07 Nov 2019 15:05:49 +0900 > Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Ingo Rohloff <ingo.rohloff@xxxxxxxxxxxxxx> 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.
