Question on case insensitive systems.

Paweł Redzyński· Mar 13, 2020, 12:05 UTC · lore

Hello, I noticed that check for filename collision on case insensitive systems happen only upon clone: https://github.com/git/git/blob/c522f061d551c9bb8684a7c3859b2ece4499b56b/entry.c#L499 and https://github.com/git/git/blob/c522f061d551c9bb8684a7c3859b2ece4499b56b/unpack-trees.c#L445

 What if collision exists on some commit that is checked out only after clone?

Is this behavior intentional (eg. for performance reasons)? If its a bug, can I volunteer to solve it? Best regards Paweł

Torsten Bögershausen· Mar 13, 2020, 15:22 UTC · re: Paweł Redzyński · lore

Re: Question on case insensitive systems.

On Fri, Mar 13, 2020 at 01:05:46PM +0100, Paweł Redzyński wrote:

Show 8 quoted lines

> Hello,
> I noticed that check for filename collision on case insensitive
> systems happen only upon clone:
> https://github.com/git/git/blob/c522f061d551c9bb8684a7c3859b2ece4499b56b/entry.c#L499
> and
> https://github.com/git/git/blob/c522f061d551c9bb8684a7c3859b2ece4499b56b/unpack-trees.c#L445
>
>  What if collision exists on some commit that is checked out only after clone?

The OS will overwrite e.g. the content of "FILE.TXT" with "file.txt" if both exist in the repo. (Or the other way around) As a result, "FILE.TXT" would have the contents of "file.txt" which is typically different, and Git will report "FILE.TXT" as "modified".

>
> Is this behavior intentional (eg. for performance reasons)?

That depends on the definition of "performance". The Git-developpers have not yet implemented a better solution, since most of them do such things in their spare time.

As a consequence, we haven't been able to measure the performance on a computer running Git.

>If its a bug, can I volunteer to solve it?

I would call it a feature, worth to be implemented. And of course, you are wellcome to solve it. I (and probably many others) are happy to help with code-reviews and other tips, hints, suggestions.

> Best regards
> Paweł