Brian Gernhardt <benji@xxxxxxxxxxxxxxxxxx> writes:
> On Feb 3, 2007, at 3:51 PM, Junio C Hamano wrote:
>
>> A filesystem that reports success on creat(path) and then does
>> not return that path to later readdir() from that directory is
>> broken from git's point of view. At least that has been the
>> definition so far.
>
> I agree, it's fairly idiotic and obtuse. By using the great Google,
> I've seen lots of other people complaining about it as well.
I am not sure if we are really agreeing, but I'll let it pass.
> "git add ." works just fine, as it reads the name of the file from
> disk which is already in the form HFS+ accepts. The only confusion
> exists when comparing data from the user to data from disk.
I wonder even if that is true.
Luckily or unluckily, I do not have access to a system with
broken readdir() vs creat() confusion, so I cannot test it
myself, but I suspect that this sequence may not work as
expected:
#!/bin/sh
pathname='a pathname that canonicalize differently from original'
rm -fr testrepo
mkdir testrepo
cd testrepo
git init-db
echo hello >"$pathname"
git add -f .
git ls-files -s "$pathname"
If my reading of what you said is correct, then in the above
sequence:
(1) The shell creates, via redirection of output of echo, a file
but using canonicalized string, which is different from
what the user gave;
(2) "git add" will ask readdir(2) to get inventory of files in
the working directory, and grabs canonicalized string;
(3) "git add" uses that canonicalized string, open(2)s, mmap(2)s and
hashes the blob contents and registers that object name
under the canonicazlied string in the index;
(4) "git ls-files" tries to look up the index with the string
user used to create the file in (1), which is without the
canonicalization.
I think it is fairly idiotic and obtuse for a filesystem to
treat pathnames anything but a random sequence of bytes that is
slash separated and NUL terminated. I would need a really hard
convincing to buy any path munging on the git side to match
whatever a stupid filesystem does, especially because we do not
live in the ideal Unicode/utf-8 only world.
-
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