Re: What's cooking in git.git (Oct 2017, #07; Mon, 30)

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Junio,

On Tue, 31 Oct 2017, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@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