David Turner <dturner@xxxxxxxxxxxxxxxx> writes: > 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? 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html