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:
\\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
More majordomo info at

Reply via email to