{"thread":{"id":"36768","subject":"RFC: optionally reject case-clone branch names","startedAt":"2014-05-27T22:56:08Z","lastAt":"2014-05-28T21:58:12Z","messageCount":4,"participants":["David Turner","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"242823","messageId":"1401231368.18134.63.camel@stross","threadId":"36768","inReplyTo":null,"subject":"RFC: optionally reject case-clone branch names","fromName":"David Turner","fromEmail":"dturner@twopensource.com","sentAt":"2014-05-27T22:56:08Z","receivedAt":"2014-05-27T22:56:08Z","isPatch":false,"sender":{"key":"novalis@novalis.org","avatar":"https://avatars.githubusercontent.com/u/77003?v=4"},"body":"At present, it is possible to have two branches which are the same but\nfor case. This works great on the case-sensitive filesystems, but not\nso well on case-insensitive filesystems. It is fairly typical to have\ncase-insensitive clients (Macs, say) with a case-sensitive server\n(GNU/Linux). \n\nShould you attempt to pull on a Mac when you have case-clone branches\nwith differing contents, you'll get an error message containing\nsomething like \"Ref refs/remotes/origin/lower is at\n[sha-of-lowercase-branch] but expected [sha-of-uppercase-branch]....\n(unable to update local ref)\"\n\nFortunately, nobody uses Macs for git servers, because on a Mac server,\nif you push a branch called capital-M Master (that differs from\nlowercase-m-master), nobody else can push to (lowercase-m) master until\nthe branch is removed. Once the branch has been removed, it can no\nlonger be recreated.\n\nI think a git client that used only packed-refs would not have any\nproblems with case-sensitivity of branch names, but I assume that there\nare good reasons this hasn't yet been done. At any rate, there are\nplenty of older clients out there.\n\nRFC follows:\n\n1. On a case-insensitive server, git receive-pack ought to always reject\nbranches which are same-but-for-case of existing branches.\n2. On a case-sensitive server, the same rule by default, with an option\nto allow the old behavior.\n\nLet me know if, should I write these patches, they would be likely to be\naccepted.\n"},{"id":"242872","messageId":"xmqq7g55esg5.fsf@gitster.dls.corp.google.com","threadId":"36768","inReplyTo":"1401231368.18134.63.camel@stross","subject":"Re: RFC: optionally reject case-clone branch names","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-28T17:14:34Z","receivedAt":"2014-05-28T17:14:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Turner writes:\n\n> RFC follows:\n>\n> 1. On a case-insensitive server, git receive-pack ought to always reject\n> branches which are same-but-for-case of existing branches.\n> 2. On a case-sensitive server, the same rule by default, with an option\n> to allow the old behavior.\n>\n> Let me know if, should I write these patches, they would be likely to be\n> accepted.\n\nThere is another a lot simpler possiblity, no?\n\n3. On any server whose administrator chooses to enforce \"one case\n variant only\" rule, install a pre-receive hook that enforces the\n rule.\n"},{"id":"242877","messageId":"1401299791.18134.74.camel@stross","threadId":"36768","inReplyTo":"xmqq7g55esg5.fsf@gitster.dls.corp.google.com","subject":"Re: RFC: optionally reject case-clone branch names","fromName":"David Turner","fromEmail":"dturner@twopensource.com","sentAt":"2014-05-28T17:56:31Z","receivedAt":"2014-05-28T17:56:31Z","isPatch":false,"sender":{"key":"novalis@novalis.org","avatar":"https://avatars.githubusercontent.com/u/77003?v=4"},"body":"On Wed, 2014-05-28 at 10:14 -0700, Junio C Hamano wrote:\n> David Turner writes:\n> \n> > RFC follows:\n> >\n> > 1. On a case-insensitive server, git receive-pack ought to always reject\n> > branches which are same-but-for-case of existing branches.\n> > 2. On a case-sensitive server, the same rule by default, with an option\n> > to allow the old behavior.\n> >\n> > Let me know if, should I write these patches, they would be likely to be\n> > accepted.\n> \n> There is another a lot simpler possiblity, no?\n> \n> 3. On any server whose administrator chooses to enforce \"one case\n> variant only\" rule, install a pre-receive hook that enforces the\n> rule.\n\nThe reason I discovered this issue is that a user came to me to complain\nthat suddenly their pulls were failing. Then I had to track down what\nthe actual problem was (a colleague actually pointed it out to me).\n\nWe could add some hooks, but we have a lot of repos, some of which\nalready have unique hooks that we would have to edit. And this approach\nwouldn't help the next person who gets into this situation, who would\nhave to again figure out what went wrong, and add the appropriate hook.\n\nBasically, I'm trying to take a poka-yoke approach. Does this seem\nreasonable?\n"},{"id":"242910","messageId":"xmqqy4xlbm6j.fsf@gitster.dls.corp.google.com","threadId":"36768","inReplyTo":"1401299791.18134.74.camel@stross","subject":"Re: RFC: optionally reject case-clone branch names","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-28T21:58:12Z","receivedAt":"2014-05-28T21:58:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Turner writes:\n\n> On Wed, 2014-05-28 at 10:14 -0700, Junio C Hamano wrote:\n>> David Turner writes:\n>> \n>> > RFC follows:\n>> >\n>> > 1. On a case-insensitive server, git receive-pack ought to always reject\n>> > branches which are same-but-for-case of existing branches.\n>> > 2. On a case-sensitive server, the same rule by default, with an option\n>> > to allow the old behavior.\n>> >\n>> > Let me know if, should I write these patches, they would be likely to be\n>> > accepted.\n>> \n>> There is another a lot simpler possiblity, no?\n>> \n>> 3. On any server whose administrator chooses to enforce \"one case\n>> variant only\" rule, install a pre-receive hook that enforces the\n>> rule.\n>\n> The reason I discovered this issue is that a user came to me to complain\n> that suddenly their pulls were failing. Then I had to track down what\n> the actual problem was (a colleague actually pointed it out to me).\n>\n> We could add some hooks, but we have a lot of repos, some of which\n> already have unique hooks that we would have to edit. And this approach\n> wouldn't help the next person who gets into this situation, who would\n> have to again figure out what went wrong, and add the appropriate hook.\n>\n> Basically, I'm trying to take a poka-yoke approach. Does this seem\n> reasonable?\n\nSort of. I think #1 is uncontroversial; there is nothing else that\ncan be done that is more sensible. As to #2, as your Subject line\nsays, I think it should be \"optionally reject\", that is, \"the old\nbehaviour by default, with an option to allow the same ruleas #1\".\n"}]}