From: Johannes Sixt <j.sixt@viscovery.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Ralf Thielow <ralf.thielow@gmail.com>, git@vger.kernel.org
Subject: Re: t6200: avoid path mangling issue on Windows
Date: Fri, 19 Apr 2013 07:48:06 +0200 [thread overview]
Message-ID: <5170DA96.9000300@viscovery.net> (raw)
In-Reply-To: <7v38un93br.fsf@alter.siamese.dyndns.org>
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?
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
next prev parent reply other threads:[~2013-04-19 5:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-07 15:25 [PATCH 1/2] fmt-merge-msg: respect core.commentchar in people credits Ralf Thielow
2013-04-07 15:25 ` [PATCH 2/2] fmt-merge-msg: use core.commentchar in tag signatures completely Ralf Thielow
2013-04-18 6:42 ` t6200: avoid path mangling issue on Windows Johannes Sixt
2013-04-18 17:05 ` Junio C Hamano
2013-04-19 5:48 ` Johannes Sixt [this message]
2013-04-19 16:33 ` Junio C Hamano
2013-04-19 19:46 ` Johannes Sixt
2013-04-19 21:22 ` Junio C Hamano
2013-04-21 0:05 ` Jonathan Nieder
2013-04-21 6:22 ` Johannes Sixt
2013-04-21 6:35 ` Jonathan Nieder
2013-04-21 7:12 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5170DA96.9000300@viscovery.net \
--to=j.sixt@viscovery.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=ralf.thielow@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).