Re: t6200: avoid path mangling issue on Windows

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: t6200: avoid path mangling issue on Windows

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:56:54

Johannes Sixt [off-list ref] writes:
From: Johannes Sixt <redacted>

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 <redacted>
...
-	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.

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

Thanks.

Re: t6200: avoid path mangling issue on Windows

From: Johannes Sixt <hidden>
Date: 2016-06-15 22:56:54

Am 4/18/2013 19:05, schrieb Junio C Hamano:
Johannes Sixt [off-list ref] writes:
quoted
From: Johannes Sixt <redacted>

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 <redacted>
...
-	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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help