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

From: Jiang Xin <worldhello.net@gmail.com>
Date: Sep 11, 2013, 04:41 UTC
Message-ID: <CANYiYbECYK90Hp49rd9Ow8X_CdcnKREeSafwHTXRnut+qABMqA@mail.gmail.com>
In-Reply-To: <loom.20130911T001650-550@post.gmane.org>

2013/9/11 Karsten Blees <karsten.blees@gmail.com>:

Show 19 quoted lines

> 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