threads / discuss / 36768

RFC: optionally reject case-clone branch names

Subject: RFC: optionally reject case-clone branch names

## tl;dr

4 messages between May 27, 2014 and May 28, 2014.

replies: 3people: 2as markdown or json

David Turner· May 27, 2014, 22:56 UTC · lore

At present, it is possible to have two branches which are the same but for case. This works great on the case-sensitive filesystems, but not so well on case-insensitive filesystems. It is fairly typical to have case-insensitive clients (Macs, say) with a case-sensitive server (GNU/Linux).

Should you attempt to pull on a Mac when you have case-clone branches with differing contents, you'll get an error message containing something like "Ref refs/remotes/origin/lower is at [sha-of-lowercase-branch] but expected [sha-of-uppercase-branch].... (unable to update local ref)"

Fortunately, nobody uses Macs for git servers, because on a Mac server, if you push a branch called capital-M Master (that differs from lowercase-m-master), nobody else can push to (lowercase-m) master until the branch is removed. Once the branch has been removed, it can no longer be recreated.

I think a git client that used only packed-refs would not have any problems with case-sensitivity of branch names, but I assume that there are good reasons this hasn't yet been done. At any rate, there are plenty of older clients out there.

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.

Junio C Hamano· May 28, 2014, 17:14 UTC · re: David Turner · lore

Re: RFC: optionally reject case-clone branch names

David Turner <dturner@twopensource.com> writes:
Show 9 quoted lines
> 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.
David Turner· May 28, 2014, 17:56 UTC · re: Junio C Hamano · lore

Re: RFC: optionally reject case-clone branch names

On Wed, 2014-05-28 at 10:14 -0700, Junio C Hamano wrote:
Show 17 quoted lines
> David Turner <dturner@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?

Junio C Hamano· May 28, 2014, 21:58 UTC · re: David Turner · lore

Re: RFC: optionally reject case-clone branch names

David Turner <dturner@twopensource.com> writes:
Show 30 quoted lines
> On Wed, 2014-05-28 at 10:14 -0700, Junio C Hamano wrote:
>> David Turner <dturner@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".

← back to recent threads