Re: Regression in e02ca72: git svn rebase is broken on Windows

Junio C Hamano <gitster <at> pobox.com> writes:

Tvangeste <i.4m.l33t <at> yandex.ru> writes:

quoted

Hi,

After bisecting this problem I ended up with the mentioned commit that

completely breaks git-svn for me on

Windows (mingw/msys version).

quoted

==========
#> git svn rebase
warning: unable to access '': Invalid argument
warning: unable to access '': Invalid argument
fatal: unable to access '../../../../w:/work/my/repo.git/.git/config':

Invalid argument

quoted

fatal: index file open failed: Invalid argument
Cannot rebase: You have unstaged changes.
Please commit or stash them.
rebase refs/remotes/trunk: command returned error: 1
==========

Please note that I use the official git repository as-is, this one (no

additional patches):

quoted

git://git.kernel.org/pub/scm/git/git.git

e02ca72f70ed8f0268a81f72cb3230c72e538e77 is the first bad commit
commit e02ca72f70ed8f0268a81f72cb3230c72e538e77
Author: Jiang Xin
Date:   Tue Jun 25 23:53:43 2013 +0800

    path.c: refactor relative_path(), not only strip prefix

Thanks,
  --Tvangeste

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.

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
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.

Additionally, GIT_DIR now may or may not have a trailing slash, which gives
me a slightly uneasy feeling...