David Turner <dtur...@twopensource.com> writes:

> On Wed, 2014-05-28 at 10:14 -0700, Junio C Hamano wrote:
>> David Turner <dtur...@twopensource.com> 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?

Sort of.  I think #1 is uncontroversial; there is nothing else that
can be done that is more sensible.  As to #2, as your Subject line
says, I think it should be "optionally reject", that is, "the old
behaviour by default, with an option to allow the same ruleas #1".
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to