Re: RFC: optionally reject case-clone branch names

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2014-05-28 at 10:14 -0700, Junio C Hamano wrote:
> David Turner <dturner@xxxxxxxxxxxxxxxx> writes:
> 
> > RFC follows:
> >
> > 1. On a case-insensitive server, git receive-pack ought to always reject
> > branches which are same-but-for-case of existing branches.
> > 2. On a case-sensitive server, the same rule by default, with an option
> > to allow the old behavior.
> >
> > Let me know if, should I write these patches, they would be likely to be
> > accepted.
> 
> There is another a lot simpler possiblity, no?
> 
> 3. On any server whose administrator chooses to enforce "one case
>    variant only" rule, install a pre-receive hook that enforces the
>    rule.

The reason I discovered this issue is that a user came to me to complain
that suddenly their pulls were failing.  Then I had to track down what
the actual problem was (a colleague actually pointed it out to me).

We could add some hooks, but we have a lot of repos, some of which
already have unique hooks that we would have to edit.  And this approach
wouldn't help the next person who gets into this situation, who would
have to again figure out what went wrong, and add the appropriate hook.

Basically, I'm trying to take a poka-yoke approach. Does this seem
reasonable?

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]