On 22/01/2008, Junio C Hamano <gitster@xxxxxxxxx> wrote: > "Reece Dunn" <msclrhd@xxxxxxxxxxxxxx> writes: > > > 1. File name representation > > > > For Linux file systems ... > > Therefore, you have: > > > > os_to_git_path( const NATIVECHAR * ospath, strbuf * gitpath ); > > git_to_os_path( const char * gitpath, const NATIVECHAR * ospath, int oslen ); > > It is not that simple, I am afraid. Legacy encodings can be > used in pathnames. With bog-standard traditional UNIX pathname > semantics, all pathnames are sequences of non-NUL, non-slash > bytes, separated with slashes, so if you do not allow choices > (which is a very sensible ideal world scenario), you can declare > that the "git" encoding is UTF-8 and always check things out > as-is. So the upshot of this is that you need to use a platform (Operating System, filesystem, locale, etc.) that match what the git repository was created in, otherwise there are going to be issues when interpreting paths correctly. The locale issue asside, can the above proposal help users working on Mac, Linux and Windows interoperate with each other? I understand that there is not going to be a universal magic fix; what I'm interested in is minimising the differences between Operating Systems. This may be a futile effort, as it is likely you will need some knowledge of the properties of the filesystem being used (as filesystems with different properties can be used on the same Operating System). > > 2. Case (in)sensitivity > > > > Here, you have the following cases: > > ... > > 3. git says that the files are different, but the filesystem says > > that the files are the same. > > > > Allow the move, updating the git directory tree only. > > Sorry, I cannot really tell what you are talking about. You > seem to imply, with "Allow the move", that you are describing a > scenario that involves a move of one existing file to another, > but it is not clear. E.g. did you mean, by 3, "When the user > says 'move a b', and if git says a and b are different but if > the filesystem says a and b are the same, then..."? This is what I am saying. For example, if you say: git mv myfile.H myfile.h on a case sensitive filesystem (e.g. ext3), this will work, however on a case insensitive filesystem (e.g. ntfs) git would complain that the files are the same. The workaround is to say: git mv myfile.H myfile.h.tmp git mv myfile.h.tmp myfile.h but this is not ideal, especially if you are automating some move operations. This also applies to the VCS importers (e.g. git-p4) that can delete a file that is a case-only move on case insensitive filesystems. The question then becomes what happens on Mac (with the Unicode decomposing behaviour) if they differ in the way they are stored (e.g. in Linus' 'ä' vs 'a¨' example)? - Reece - 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
