2013/9/11 Karsten Blees <karsten.blees@xxxxxxxxx>: > Junio C Hamano <gitster <at> pobox.com> writes: > >> The suspect commit and symptom look consistent. You started from a >> directory whose absolute path is "w:/work/..." and the updated code >> mistakenly thoguht that something that begins with "w" (not '/') is >> not an absolute, so added a series of ../ to make it relative, or >> something silly like that. >> >> Jiang? >> > > Indeed, this patch seems to change relative_path in a way that breaks git > initialization, not just on Windows. > > Previously, relative_path was always called with two absolute paths, and it > only returned a relative path if the first was a subdir of the second (so a > better name would probably have been 'relative_path_if_subdir'). The purpose > was to improve performance by making GIT_DIR shorter if it was a subdir of > GIT_WORK_TREE. Yes, it's what commit v1.5.6-1-g044bbbc says. > After this patch, relative_path always tries to return a relative path, even > if both absolute paths are completely disjunct. This not only defeats the > purpose (by making GIT_DIR longer, thus hurting performance), it is also not Sometimes longer, sometimes shorter maybe. > possible in general. POSIX explicitly allows for '//hostname' notation > referring to network resources that are not explicitly mounted under '/'. > I.e. given two absolute paths '//hostname1/a' and '//hostname2/b', there is > no relative path from a to b or vice versa. Yes, path like "//hostname/path" can be used on Windows. My hack "have_same_root" does not cover this case, so using a "simple_relative_path" function instead of "relative_path" in setup.c may be the better. -- Jiang Xin -- 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