Re: t6200: avoid path mangling issue on Windows

[Johannes Sixt <j6t@kdbg.org>]

Am 19.04.2013 18:33, schrieb Junio C Hamano:
> Johannes Sixt <j.sixt@viscovery.net> writes:
> 
>> Am 4/18/2013 19:05, schrieb Junio C Hamano:
>>> 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?
> 
> When the user passes key=value and value begins with a slash, value
> may be a path in the filesystem very often, and adjusting it to the
> local filesystem convention helps Windows users a lot.
> 
> But there are cases outside that very often when the user wants the
> value passed literally.  There seems to be no way to do so.
> ...
> if bash could be told with a very unnatural and not so hard to type
> way that the particular value is not to be mangled, e.g.
> 
> 	xyzzy key="""/a/b/c"""

I'll not argue whether such a feature would make sense or not, or
whether it can be implemented, because it is aimed at the user, but
misses one important point: It does in no way help our development process.

A patch auther whose first instinct is to write 'foo=/' will never write
'foo=x', let alone 'foo="""/"""'. Someone will have to discover the
issue eventually and write a patch to fix it, and someone will have to
apply it.

I don't think that we can do anything about it.

-- Hannes