On Jan 25, 2008 11:31 AM, Nicolas Pitre <nico@cam.org> wrote:
quoted text
> On Thu, 24 Jan 2008, Junio C Hamano wrote:
>
> > 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html