On Jan 25, 2008 11:31 AM, Nicolas Pitre <nico@xxxxxxx> wrote: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
