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 offhand the implications of the change you propose to make to match_one(), but it could also be the place to handle case-challenged filesystems.
I would simply like match_one to agree with the file system as to what is a match. On OS X that would mean that both normalized forms of UTF-8 match. I'm trying it as a proof-of-concept mostly to see what kind of effects it would have. match_one only seems to be used in match_pathspec, which is only used by add and rm... And I think that getting it to match the behavior of the OS would make things less surprising for the user.
But even if you do that, I wonder what your plan would be to handle something like "git add .". read_directory_recursive() asks readdir() for existing pathnames, and we expect that can be used as parameter to add_file_to_index and then eventually we can call creat() or symlink() with it, so it also needs to be taught to behave consistently with respect to what your updated match_one() does.
"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.
In any case, I don't appear to understand the proper incantations to bend ICU to my will, as it either doesn't change anything or breaks git completely. Perhaps further attempts will help, but my lack of experience with the API is a serious hinderance, and I can't find any other way to do the normalization.
~~ Brian - 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