Am 19.04.2013 18:33, schrieb Junio C Hamano: > Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes: > >> Am 4/18/2013 19:05, schrieb Junio C Hamano: >>> Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes: >>> >>>> From: Johannes Sixt <j6t@xxxxxxxx> >>>> >>>> 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@xxxxxxxx> >>>> ... >>>> - 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html