[PATCH] Fix issue 1763 by stripping \r from gitpatch reported path

Bill Barry after.fallout at gmail.com
Fri Jul 24 15:10:45 CDT 2009


Eric M. Hopper wrote:
> On Fri, 2009-07-24 at 16:27 +0000, Bill Barry wrote:
>   
>> # HG changeset patch
>> # User Bill Barry <after.fallout at gmail.com>
>> # Date 1248452792 21600
>> # Node ID 384618d1871a0923aa1715fcdd8d227a66e0455c
>> # Parent  65719472bfa2cde9630b2fc019688d95327d3e69
>> Fix issue 1763 by stripping \r from gitpatch reported path
>>
>> diff --git a/mercurial/patch.py b/mercurial/patch.py
>> --- a/mercurial/patch.py
>> +++ b/mercurial/patch.py
>> @@ -1022,7 +1022,7 @@
>>              for gp in gitpatches:
>>                  if gp.op in ('COPY', 'RENAME'):
>>                      copyfile(gp.oldpath, gp.path, cwd)
>> -                changed[gp.path] = gp
>> +                changed[gp.path.rstrip('\r')] = gp
>>          else:
>>              raise util.Abort(_('unsupported parser state: %s') % state)
>>     
>
> As an item of curiosity, how do git patches currently handle filenames
> with control characters in them?
I have no idea. Perhaps that is a better question for the list at large?

I merely came across this as part of trying to figure out why attic 
wasn't working on windows this week after I did some updates. I am not 
convinced that this is a good solution to the problem either (pmezard 
stated in bts that diff headers are supposed to be LF only endings no 
matter where they come from, but I have been able to generate CRLF 
headers in several different ways that I have generated a patch). This 
patch will certainly not work with any files that legitimately have CR 
chars at the end of them (though I suspect that files which have LF 
would break the diff header format system as well; other control 
characters are probably safe in that they aren't dealt with explicitly).

I think it would be best if at all possible to not use any control chars 
in a file name as weird things may very well happen with many different 
systems. If it were up to me I would say control chars are disallowed in 
filenames (and the only things we would have to worry about would be 
exploits for them).  I would hazard to guess there is probably problems 
with certain unicode filename chars as well (filenames should be bytes, 
not code points, and for that matter code points should not have bytes 
that could be read as control chars when processed on a per-byte basis; 
the whole thing is fubared pretty badly).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial-devel/attachments/20090724/57cb9f52/attachment.htm 


More information about the Mercurial-devel mailing list