git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: t6200: avoid path mangling issue on Windows

From
Junio C Hamano <gitster@pobox.com>
Date
Apr 19, 2013, 16:33 UTC
Message-ID
<7vr4i632fp.fsf@alter.siamese.dyndns.org>
In-Reply-To
<5170DA96.9000300@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
Show 24 quoted lines
> 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.

That is the issue I was wondering. If there is a clean solution to disable path mangling per token, we could cleanly solve it.

For example, while making sure that a value that begins with slash in normal cases is still adjusted, i.e. mangling all of the following,

	xyzzy key=/a/b/c
        xyzzy key="/a/b/c"
        value=/a/b/c; xyzzy key="$value"
        value=/a/b/c; xyzzy "key=$value"

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"""
        value=/a/b/c; xyzzy """key=$value"""

which a normal bash would interpret as the concatenation of an empty string inside dq, /a/b/c/ (or key=$value) inside dq, and an empty string inside dq, which is the same as /a/b/c (or key=$value) inside dq, it would help the less common case. Nobody would type a string surrounded by two empty strings to be concatenated on purpose (i.e. very unnatural) and typing the same dq four more times than you would normally do is not too much of a hassle (not so hard to type). The problematic case can then be fixed to

	git -c core.commentchar="""/""" fmt-merge-msg ...
and it will work the same way on and off Windows.
Previous: Johannes SixtNext: Johannes Sixt
Message 6 of 12 in “fmt-merge-msg: respect core.commentchar in people credits”
  1. 1/2 fmt-merge-msg: respect core.commentchar in people creditsRalf Thielow, Apr 7, 2013
  2. 2/2 fmt-merge-msg: use core.commentchar in tag signatures completelyRalf Thielow, Apr 7, 2013
  3. t6200: avoid path mangling issue on WindowsJohannes Sixt, Apr 18, 2013
  4. Junio C HamanoApr 18, 2013
  5. Johannes SixtApr 19, 2013
  6. Junio C HamanoApr 19, 2013
  7. Johannes SixtApr 19, 2013
  8. Junio C HamanoApr 19, 2013
  9. Jonathan NiederApr 21, 2013
  10. Johannes SixtApr 21, 2013
  11. Jonathan NiederApr 21, 2013
  12. Junio C HamanoApr 21, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.