<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Eric M. Hopper wrote:
<blockquote cite="mid:1248459376.29225.148.camel@bats.omnifarious.org"
 type="cite">
  <pre wrap="">On Fri, 2009-07-24 at 16:27 +0000, Bill Barry wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap=""># HG changeset patch
# User Bill Barry <a class="moz-txt-link-rfc2396E" href="mailto:after.fallout@gmail.com">&lt;after.fallout@gmail.com&gt;</a>
# 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)
    </pre>
  </blockquote>
  <pre wrap=""><!---->
As an item of curiosity, how do git patches currently handle filenames
with control characters in them?</pre>
</blockquote>
I have no idea. Perhaps that is a better question for the list at large?<br>
<br>
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).<br>
<br>
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).&nbsp; 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).<br>
</body>
</html>