Re: [PATCH 1/2] init-db.c: honor case on case preserving fs

[Junio C Hamano <gitster@pobox.com>]

Torsten Bögershausen <tboegi@web.de> writes:

> On 2014-02-01 10.14, Reuben Hawkins wrote:
>> Most case-insensitive filesystems are case-preserving. In these
>> filesystems (such as HFS+ on OS X) you can name a file Filename.txt,
>> then rename the file to FileName.txt.  That file will be accessible
>> by both filenames, but the case is otherwise honored.  We don't want
>> to have git ignore case on these case-preserving filesystem
>> implementations.
>
> Yes, we want.
> Because the file system will treat "Filename.txt" and "FileName.txt"
> the same.

Another important thing to remember is that we cannot have these two
files at the same time on such a filesystem.

Somebody may have Filename.txt in the commit at the tip of the
history, you clone/fetch and check it out, and you will have
Filename.txt with the original contents.  We do not try to corrupt
the filename on core.ignorecase filesystem by any canonicalization.

But then you may edit that file, and you either deliberately or
without knowing (because some of your tools do this behind your
back) may end up saving the result as FileName.txt.  What happens?

When we ask "what is the contents of Filename.txt now?" (using the
original name still in the index) to the underlying system, we will
be given what you placed in FileName.txt.  We won't see "You do not
have Filename.txt, but you now have FileName.txt".

And that is the behaviour the end users (of not Git, but of a
platform with such a filesystem) do expect from their tools.  They
do not want to see "You no longer have Filename.txt, and you have a
new file FileName.txt".

Now think what "git add Filename.txt" should do at that point?  It
should not say "I was told to add Filename.txt, but there is no such
file, so I'll add nothing".  If you run "git add -u Filename.txt",
it should not say "I was told to add Filename.txt, but there is no
such file, so I'll remove existing Filename.txt from the index".

It must pick up the updated contents from your new FileName.txt,
update the index entry "Filename.txt", and the next "git commit"
must record it as an update to the same file.

If you are on the other hand trying to correct an earlier mistake of
having named the file "Filename.txt" but you now want to rename it
"FileName.txt", the above behaviour by core.ignorecase may make it a
bit cumbersome to do.  You can first remove it from the index and
then re-add it, I would think, as a workaround.  Having to do a
"workaround" is unfortunate but it is an unavoidable consequence of
having to choose between the two and having to pick one.  Most of
the time you do not want such a rename (or rather, the loss of the
file Filename.txt and the creation of the unrelated FileName.txt)
and a change from Filename.txt to FileName.txt is most likely to be
a mistake in the platform tool that mucked with the files on your
filesystem, so we choose to make it easy for the user not to be
disturbed by such a change.