Re: [PATCH 2/2] mingw: allow absolute paths without drive prefix
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Dec 13, 2018, 02:48 UTC
- Message-ID
- <xmqqmupagn0y.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <8a484f86-1d43-fc0a-22b4-39c770cda6cb@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
Show 22 quoted lines
>>>> + if (is_dir_sep(template[0]) && !is_dir_sep(template[1]) &&
>>>> + iswalpha(wtemplate[0]) && wtemplate[1] == L':') {
>>>> + /* We have an absolute path missing the drive prefix */
>>>
>>> This comment is true for the source part, template, but I can't find
>>> where the destination, wtemplate, suddenly gets the drive prefix. As far
>>> as I can see, xutftowcs_path() just does a plain textual conversion
>>> without any interpretation of the text as path. Can you explain it?
>>
>> It is legal on Windows for such a path to lack the drive prefix, also in
>> the wide-character version. So the explanation is: even `wtemplate` won't
>> get the drive prefix. It does not need to.
>
> I'm sorry, my question was extremely fuzzy. I actually wanted to know
> how the condition that you introduce in this patch can ever be true.
>
> And after looking at the Git for Windows code, I could answer it
> myself: it cannot. Not with this patch alone. In GfW, there is
> additional code in xutftowcs_path() that massages wtemplate to receive
> a drive prefix; but vanilla Git does not have that code, so that
> is_dir_sep(template[0]) and iswalpha(wtemplate[0]) can never be true
> at the same time at this point.So,... what's the conclusion? The patch in the context of my tree would be a no-op, and we'd need a prerequisite change to the support function to accompany this patch to be effective?