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.
> 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 .
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:
\\hostname\share\directory\file (same as cygwin)
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).
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