Re: t6200: avoid path mangling issue on Windows

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Apr 19, 2013, 05:48 UTC
Message-ID: <5170DA96.9000300@viscovery.net>
In-Reply-To: <7v38un93br.fsf@alter.siamese.dyndns.org>

Am 4/18/2013 19:05, schrieb Junio C Hamano:

Show 21 quoted lines

> Johannes Sixt <j.sixt@viscovery.net> writes:
> 
>> From: Johannes Sixt <j6t@kdbg.org>
>>
>> MSYS bash interprets the slash in the argument core.commentchar="/"
>> as root directory and mangles it into a Windows style path. Use a
>> different core.commentchar to dodge the issue.
>>
>> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
>> ...
>> -	git -c core.commentchar="/" fmt-merge-msg --log=5 <.git/FETCH_HEAD >actual &&
>> +	git -c core.commentchar="x" fmt-merge-msg --log=5 <.git/FETCH_HEAD >actual &&
> 
> Sigh... Again?
> 
> Are folks working on Msys bash aware that sometimes the users may
> want to say key=value on their command line without the value
> getting molested in any way and giving them some escape hatch would
> help them?  Perhaps they have already decided that it is not
> feasible after thinking about the issue, in which case I do not have
> new ideas to offer.

What is "the issue"? And in which way would an escape hatch help us here? We would have to apply a patch anyway after a glitch like this shows up, because disabling path mangling whole-sale (if there were a method -- there is none currently) is a no-go in the context of our test suite, let a lone in our scripted tool set.

When "foo=/" appears on the command line, the most obvious interpretation of the slash for a program without mind-reading mode is that it is an absolute path, and then path mangling must happen (if and only if the invoked program is a non-MSYS program such as git).

> I'll apply the patch as-is, but this feels really painful to the
> users.

No, generally, path mangling is a service for the user.

-- Hannes