Re: On pathnames

On Jan 25, 2008 11:31 AM, Nicolas Pitre [off-list ref] wrote:

On Thu, 24 Jan 2008, Junio C Hamano wrote:

quoted

If it is a new file, we won't find any name that is equivalent
to $A in the index, and we use the name $A obtained from
readdir(3).

BUT with a twist.

If the filesystem is known to be inconveniently case folding, we
are better off registering $B instead of $A (assuming we can
convert from $A to $B).

Why?

If you have no other representation for the file name than $A already,
then I don't see why Git would have to play similar evil games and
corru^H^H^Hnvert $A into $B.  Just store $A in the index and tree
objects and be done with it.

Because if you happen to be on a case-challenged filesystem, and you
need to add a new file - say xt_CONNBARK.c, you can, even if your FS
only has xt_connbark.c to offer to git. Granted, it's harder, but it
can be done, and it means that powerusers and wrappers around git have
a hope of dealing with it.

I think this is an excellent plan.

There is one thing that I don't see in Junio's plan -- which is
excellent -- and is

 - a warning during checkout if the index contains "equivalent" paths
that will clobber eachother during checkout.
 - an optional warning/error during add, to be raised if I am adding a
path that is equivalent to an already-existing path in the index

The second one is to support project that are known to be developed on
these non-filename-preserving platforms. So if I am on a linux host,
and I add Readme where README already exists, a warning can save me
and the project a bit of grief - and possibly catch an unintended
mistake! Because while I agree that users should be able to store any
file in git, in practice most instances of Ma"rchen/Märchen case will
be due to user error (or editor/gui error).

cheers,


m