Re: On pathnames

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*