Hi Junio, On Tue, 31 Oct 2017, Junio C Hamano wrote:
> Johannes Schindelin <johannes.schinde...@gmx.de> writes: > > > On Mon, 30 Oct 2017, Junio C Hamano wrote: > > > >> * jc/branch-name-sanity (2017-10-14) 3 commits > >> (merged to 'next' on 2017-10-16 at 174646d1c3) > >> + branch: forbid refs/heads/HEAD > >> + branch: split validate_new_branchname() into two > >> + branch: streamline "attr_only" handling in validate_new_branchname() > >> > >> "git branch" and "git checkout -b" are now forbidden from creating > >> a branch whose name is "HEAD". > > > > Question: should we respect core.ignoreCase and if it is true, compare > > case-insensitively? Or should we just keep the comparison > > case-sensitively, in preparation for a (hopefully near) refs backend that > > does not inherit filesystems' case-insensitivity? > > While I do think it would be good if the system as a whole somewhere > we had a safety to say "We do not allow hEaD as branch name as you > are using the files-backend as your reference storage on a case > insensitive filesystem", I do not think it is a good idea to do so > in the layer the above patches touch. Once a more capable ref > backend comes (Shawn's reftable, anybody???), platforms with case > insensitive filesystems can allow refs/heads/hEaD as a branch whose > name is hEaD that is different from another branch whose name is > hEAD just fine; having the "we are on icase system, so reject" check > at the layer would mean we need to remember we have such a check at > a wrong layer and revert it when such an improvement happens. I am glad you covered that concern, thanks! Dscho
