Open GoogleCodeExporter opened 9 years ago
You have the root cause right. The question is, what to do about this? You
would
have to tell Python somehow that it should only treat CRLF as a line ending.
(In
effect this is how the Microsoft C library interprets line endings in text
mode.)
This is a property of the file, so unless GIT sends along the fact that the diff
should be interpreted this way, I'm not sure how Rietveld can guess this. Maybe
upload.py can request this info from GIT if it detects a CR anywhere in the
file?
Original comment by gvanrossum@gmail.com
on 31 Aug 2009 at 8:22
Could you provide a reproducable example? The issue links at the top are broken
(404) and when I try
to reproduce it locally the newlines are all normalized to '\n'. That's the
diff I've uploaded:
[master] $ git diff
diff --git a/hello b/hello
index 6b9e844..7f65266 100644
--- a/hello
+++ b/hello
@@ -1,3 +1,3 @@
foo
-hello
-bar
+hello^M
+bar^M
[master] $
The side-by-side view looks fine with this changeset.
Original comment by albrecht.andi
on 1 Sep 2009 at 4:27
Strange, the links works fine for me. Can you try them again?
A file is attached with the first line end with '\r\r\n'. I can reproduce it on
a
fresh built Git 1.5.6.5(Linux 2.6.16.60).
To reproduce: (On Linux)
1. add this file to Git
2. change the second line
3. upload
And I can reproduced this issue on Mercurial.
Have you set git config core.autocrlf? But I can get it reproduced whether it
is set
or not.
Original comment by lihaitao
on 1 Sep 2009 at 8:46
Attachments:
Only operating systems "Commodore machines, Apple II family, Mac OS up to
version 9
and OS-9" represents newline with CR, according to Wikipedia.
(http://en.wikipedia.org/wiki/Newline#Representations) If Rietveld isn't
targeting
these OSs, maybe str.splitlines() can be replaced with "str.replace('\r\n',
'\n').split('\n')[:-1]"?
>>> "foo\r\r\nbar\r\n".replace('\r\n', '\n').split('\n')[:-1]
['foo\r', 'bar']
>>> "foo\r\nbar\n".replace('\r\n', '\n').split('\n')[:-1]
['foo', 'bar']
Original comment by lihaitao
on 2 Sep 2009 at 6:55
Original comment by albrecht.andi
on 6 Apr 2012 at 7:12
This bothered me for so long, working an a multi-system team with SVN. I made
this useful app, that navigates a folder with sub-folders looking for text
files and converts all UNIX EOL to DOS EOL. It is an AIR app, works on both
Windows and Mac. hope it helps
http://www.pippoflash.com/index.php/2012/06/11/svn-error-inconsistent-line-endin
g-style-nightmare-solved-download-app/
Filippo
Original comment by pippomu...@gmail.com
on 12 Jun 2012 at 12:29
Original issue reported on code.google.com by
lihaitao
on 29 Aug 2009 at 1:49