Am 12.09.2013 11:12, schrieb Jiang Xin: > Tvangeste found that the "relative_path" function could not work > properly on Windows if "in" and "prefix" have dos driver prefix. > ($gmane/234434) > > e.g., When execute: test-path-utils relative_path "C:/a/b" "D:/x/y", > should return "C:/a/b", but returns "../../C:/a/b", which is wrong. > > So make relative_path honor dos_drive_prefix, and add test cases > for it in t0060. >
I still don't think that cd'ing through the root is a Good Thing for absolute paths, as it is not possible to do so in general. POSIX says the meaning of '//' is implementation-defined [1]. Cygwin supports //hostname/share/directory/file. You cannot cd to the hostname (i.e. root would be //hostname/share). On Windows, we have drive letters, UNC paths and namespaces: C:\directory\file \\hostname\share\directory\file (same as cygwin) \\?\C:\directory\file \\?\UNC\hostname\share\directory\file I'm not sure about '//' support on other git platforms (the most likely candidate would probably be HP-UX, as HP bought Apollo/DomainOS, which supported '//hostname/directory/file back in 1981). You could of course handle all these special cases. However, with the POSIX definition above, the only reliable and future-proof way to check if we can cd out of a path component of an _absolute_ path is to actually try it until we get an error. And we probably don't want to do actual IO in relative_path (which is pure string manipulation so far). [1] http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html#tag_21_04_12 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
