Re: RFD: Handling case-colliding filenames on case-insensitive filesystems

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

Shawn Pearce <spearce@spearce.org> writes:

> On Wed, Feb 23, 2011 at 10:56, Junio C Hamano <gitster@pobox.com> wrote:
>> Johan Herland <johan@herland.net> writes:
>>
>>> Are there better suggestions on how to deal with this?
>>
>> Just from the top off my head, perhaps you can go to the same route as
>> symbolic link support on filesystems that are not symlink-capable?
>
> I don't know how that helps here Junio. On those systems we write a
> text file holding the symlink contents. That text file name is at
> least still unique in the working directory.

Heh, I probably should have more explicitly hinted that I was suggesting
to rename, e.g. foo-1.txt, when checking out conflicting paths.  I chose
not to be precise because I knew readers were intelligent enough to read
what's between my lines themselves ;-).

Just like a text file that records link target is useless as a symlink,
such a file would be useless for its original purpose (e.g. renaming
xt_TCPMSS.c to xt_tcpmss-1.c to avoid a collision with xt_tcpmss.c would
not help when its associated Makefile wants to build xt_TCPMSS.o and
xt_tcpmss.o next to each other), just like your "treat everybody the same
way and make that a directory" approach.

I think two things are sensible to do, are relatively low hanging fruits,
and are of low risk:

 - break checkout on such a tree on incapable filesystems; and

 - per project configuration (or attribute given to paths underneath a
   particular directory) that forbids or warns addition of case colliding
   paths to the index; enforce it at write_index() codepath; and

 - if we choose to just warn in the second item above instead of downright
   forbidding, barf in cache_tree_update() codepath when the per project
   configuration (or attribute) triggers upon case colliding paths, to
   prevent a commit from being made.

I think "warn at add time, fail at write-tree time" is more preferrable,
as it might be more convenient if you can add hello.c while you still have
HELLO.c in the index as long as you do not forget to remove HELLO.c from
the index before making your next commit.