From: Johannes Sixt <j6t@kdbg•org>
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 21:46:32 +0200 [thread overview]
Message-ID: <51719F18.3020508@kdbg.org> (raw)
In-Reply-To: <7vr4i632fp.fsf@alter.siamese.dyndns.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
next prev parent reply other threads:[~2013-04-19 19:46 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
2013-04-19 16:33 ` Junio C Hamano
2013-04-19 19:46 ` Johannes Sixt [this message]
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=51719F18.3020508@kdbg.org \
--to=j6t@kdbg$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=ralf.thielow@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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