Am 19.04.2013 18:33, schrieb Junio C Hamano:
> Johannes Sixt <j.s...@viscovery.net> writes:
>> Am 4/18/2013 19:05, schrieb Junio C Hamano:
>>> Johannes Sixt <j.s...@viscovery.net> writes:
>>>> From: Johannes Sixt <j...@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 <j...@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
I don't think that we can do anything about it.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html