On Thu, 24 Jan 2008, Junio C Hamano wrote: > The same thing should apply to two files that cannot be checked > out at the same time on case insensitive filesystems. Perhaps > we could have something like: > > $ git show :xt_CONNMARK.c >xt_connmark-1.c > $ edit xt_connmark-1.c > $ git add --as xt_CONNMARK.c xt_connmark-1.c I think it would be nicer to have: $ git checkout branch Warning: xt_CONNMARK.c conflicts with xt_connmark.c; not checking it out $ git checkout xt_CONNMARK.c --as xt_CONNMARK_caps.c $ edit xt_CONNMARK_caps.c $ git add xt_CONNMARK_caps.c Where the index, when support for filesystems with filename restrictions is enabled, keeps track both of the name of the file in the project and the name of the file in the filesystem, with this mapping determined entirely by the user asking for problem files to be present under different names in the working tree. Of course, you can already do: $ git update-index --cacheinfo 100644 $(git hash-object -w xt_connmark-1.c) xt_CONNMARK.c > 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). Is it not the case that, when a user has a file in the filesystem with the name Ma"rchen, the user will still type: $ git add Märchen and so we see filenames which are convenient, and we don't overly care what readdir(3) returns for new filenames? I suppose there is the case of: $ touch Märchen $ git add . Which has to figure out what the files in foo are. But the common case for a new filename is that it gets provided by the user in argv, and the right file contents come from the one that open(2) returns, and there's no obvious way to get the filename that readdir(3) would return for a filename in argv anyway. -Daniel *This .sig left intentionally blank*
