Re: [PATCH] Disallow creating ambiguous branch names by default

[Stephen Bash <bash@genarts.com>]

----- Original Message -----
> From: "Conrad Irwin" <conrad.irwin@gmail.com>
> To: "Stephen Bash" <bash@genarts.com>
> Cc: "Junio C Hamano" <gitster@pobox.com>, git@vger.kernel.org
> Sent: Friday, August 19, 2011 2:07:53 PM
> Subject: Re: [PATCH] Disallow creating ambiguous branch names by default
>
> > Should case insensitive matches be added to the tests? This morning
> > I discovered coworkers working on branches foo and Foo thinking they
> > were on the same branch... Rather trivial to clean up, but certainly
> > caused some confusion in the office.
> 
> I can certainly see the use-case, but there's definitely a step-change
> between "this branch has the same name as something else", and "this
> branch is going to confuse you".

Good point.  I'd be curious if any of the msys/cygwin guys can comment on if/when capitalization in branch names becomes technically ambiguous?  I would think unpacked refs on a Windows machine could get complicated...  And I guess factory Macs are all formated case-insensitive as well, so the same problem might apply there.

> When trying to change the code to be
> a warning as Junio suggested, I did think about expanding the
> definition of ambiguous to include things that are merely confusing;
> however it's not clear where to stop (i.e. should we warn about
> <remotename>/<anything>, foo and f00, a branch called " " [the
> non-breaking space]). There's probably an argument for more general
> warning, but I don't think I understand when it should be shown
> well-enough.

Thanks for putting the thought into it, I agree it is a slippery slope.

Stephen