Re: [PATCH] remote-hg: unquote C-style paths when exporting

2013-10-23 Thread Antoine Pelisse
On Wed, Oct 23, 2013 at 2:45 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, Oct 22, 2013 at 3:49 PM, Antoine Pelisse apeli...@gmail.com wrote: It is true that I have expected valid output from git-fast-export. And I don't have in mind any easy solution to detect that the output

Re* [PATCH] remote-hg: unquote C-style paths when exporting

2013-10-23 Thread Junio C Hamano
Antoine Pelisse apeli...@gmail.com writes: def c_style_unescape(string): if string[0] == string[-1] == '': return string.decode('string-escape')[1:-1] return string It's in git-remote-bzr.py. Yeah, that's certainly better, Thanks, OK, so an amended one will look like

Re: Re* [PATCH] remote-hg: unquote C-style paths when exporting

2013-10-23 Thread Antoine Pelisse
On Wed, Oct 23, 2013 at 5:44 PM, Junio C Hamano gits...@pobox.com wrote: Antoine Pelisse apeli...@gmail.com writes: def c_style_unescape(string): if string[0] == string[-1] == '': return string.decode('string-escape')[1:-1] return string It's in git-remote-bzr.py. Yeah,

Re: [PATCH] remote-hg: unquote C-style paths when exporting

2013-10-22 Thread Junio C Hamano
Antoine Pelisse apeli...@gmail.com writes: git-fast-import documentation says that paths can be C-style quoted. Unfortunately, the current remote-hg helper doesn't unquote quoted path and pass them as-is to Mercurial when the commit is created. This result in the following situation: -

Re: [PATCH] remote-hg: unquote C-style paths when exporting

2013-10-22 Thread Antoine Pelisse
On Tue, Oct 22, 2013 at 9:13 PM, Junio C Hamano gits...@pobox.com wrote: Antoine Pelisse apeli...@gmail.com writes: git-fast-import documentation says that paths can be C-style quoted. Unfortunately, the current remote-hg helper doesn't unquote quoted path and pass them as-is to Mercurial

Re: [PATCH] remote-hg: unquote C-style paths when exporting

2013-10-22 Thread Felipe Contreras
On Tue, Oct 22, 2013 at 3:49 PM, Antoine Pelisse apeli...@gmail.com wrote: It is true that I have expected valid output from git-fast-export. And I don't have in mind any easy solution to detect that the output is broken, yet still accepted as a valid string by python. We could obviously