Re: [PATCH] Use "-f" when adding files with odd names in t9200.

From: Junio C Hamano <junkio@cox.net>
Date: Feb 3, 2007, 23:50 UTC
Message-ID: <7vlkje243u.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <A9623793-111E-47F7-9709-1D569333C40C@silverinsanity.com>

Brian Gernhardt <benji@silverinsanity.com> writes:

Show 9 quoted lines

> 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.