git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@osdl.org>
To: "Robin Rosenberg (list subscriber)"  <robin.rosenberg.lists@dewire.com>
Cc: Martin Langhoff <martin.langhoff@gmail.com>,
	Jon Smirl <jonsmirl@gmail.com>, Keith Packard <keithp@keithp.com>,
	git@vger.kernel.org
Subject: Re: Importing Mozilla CVS into git
Date: Sat, 3 Jun 2006 16:47:36 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0606031631480.5498@g5.osdl.org> (raw)
In-Reply-To: <200606040116.38036.robin.rosenberg.lists@dewire.com>



On Sun, 4 Jun 2006, Robin Rosenberg (list subscriber) wrote:
> 
> (Yet) Another problem is that many windows tools use CR LF as the line ending.
> Almost all windows editors default to CRLF and some detect existing line 
> endings. No editing with notepad anymore. Of course that is a problem 
> regardless of whether a git or cvs client is used. You'll get these big 
> everything-changed commits that alter between CRLF and LF.

The only sane approach there (if you want to be at all cross-platform) is 
to just force everybody to _commit_ in UNIX '\n'-only format. Especially 
as most Windows tools probably handle that fine on reading (just have 
trouble writing them).

And that shouldn't actually be that hard to do. The most trivial approach 
is to have just a pre-trigger on commits, but let's face it, that would 
not be a good "full" solution. A better one is to just make the whole
"git update-index" thing just have a "automatically ignore CR/LF" mode.

Which really shouldn't be that hard. I think it's literally a matter of 
teaching "index_fd()" in sha1_file.c to recognize text-files, and remove 
CR/LF from them. All done (except to add the flag that enables the 
detection, of course - just so that sane systems won't have the overhead 
or the "corrupt binary files" issue).

Something like this is TOTALLY UNTESTED!

(You also need to teach "diff" to ignore differences in cr/lf, and this 
patch is bad because it's unconditional, and probably doesn't work 
anyway, but hey, the idea is possibly sound. Maybe)

		Linus
---
diff --git a/sha1_file.c b/sha1_file.c
index aea0f40..6dc6a3f 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1740,9 +1740,30 @@ int index_pipe(unsigned char *sha1, int 
 	return ret;
 }
 
+static unsigned long autodetect_crlf(unsigned char *src, unsigned long size)
+{
+	unsigned long newsize = 0;
+	unsigned char *dst = src;
+	unsigned char last = 0;
+
+	while (size) {
+		unsigned char c = *src++;
+		if (last == '\r' && c == '\n') {
+			dst[-1] = '\n';
+		} else {
+			newsize++;
+			dst++;
+			if (dst != src)
+				dst[-1] = c;
+		}
+		last = c;
+	}
+	return newsize;
+}
+
 int index_fd(unsigned char *sha1, int fd, struct stat *st, int write_object, const char *type)
 {
-	unsigned long size = st->st_size;
+	unsigned long size = st->st_size, use_size;
 	void *buf;
 	int ret;
 	unsigned char hdr[50];
@@ -1755,12 +1776,15 @@ int index_fd(unsigned char *sha1, int fd
 	if (buf == MAP_FAILED)
 		return -1;
 
-	if (!type)
+	use_size = size;
+	if (!type) {
 		type = blob_type;
+		use_size = autodetect_crlf(buf, size);
+	}
 	if (write_object)
-		ret = write_sha1_file(buf, size, type, sha1);
+		ret = write_sha1_file(buf, use_size, type, sha1);
 	else {
-		write_sha1_file_prepare(buf, size, type, sha1, hdr, &hdrlen);
+		write_sha1_file_prepare(buf, use_size, type, sha1, hdr, &hdrlen);
 		ret = 0;
 	}
 	if (size)

  reply	other threads:[~2006-06-03 23:48 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-01 22:21 Importing Mozilla CVS into git Jon Smirl
2006-06-01 23:20 ` Keith Packard
2006-06-02  0:55   ` Jon Smirl
2006-06-02  2:07     ` Keith Packard
2006-06-02  2:36       ` Jon Smirl
2006-06-02  2:56         ` Shawn Pearce
2006-06-02  3:39         ` Keith Packard
2006-06-02  3:47           ` Jon Smirl
2006-06-02  3:55             ` Keith Packard
2006-06-02  4:00               ` Jon Smirl
2006-06-02  4:11                 ` Shawn Pearce
2006-06-02  4:39                   ` Pavel Roskin
2006-06-02  4:44                     ` Shawn Pearce
2006-06-02  7:46                       ` Johannes Schindelin
2006-06-02  4:44                     ` Jon Smirl
2006-06-07  9:02                       ` Igor Bukanov
2006-06-07 15:21                         ` Pavel Roskin
2006-06-07 15:30                         ` Jon Smirl
2006-06-07 15:58                           ` Jakub Narebski
2006-06-07 16:17                             ` Linus Torvalds
2006-06-07 18:29                               ` Martin Langhoff
2006-06-02  4:16                 ` Martin Langhoff
2006-06-03 23:16                   ` Robin Rosenberg (list subscriber)
2006-06-03 23:47                     ` Linus Torvalds [this message]
2006-06-04  2:24                       ` Bertrand Jacquin
2006-06-04  7:05                       ` Jakub Narebski
2006-06-04 17:55                         ` Linus Torvalds
2006-06-04 19:44                           ` Robin Rosenberg (list subscriber)
2006-06-04 20:00                             ` Linus Torvalds
2006-06-04 21:25                               ` Robin Rosenberg (list subscriber)
2006-06-04 22:02                                 ` Robin Rosenberg (list subscriber)
2006-06-04 23:19                                 ` Linus Torvalds
2006-06-05  0:10                       ` Yakov Lerner
2006-06-03  0:09               ` Jon Smirl
2006-06-03  4:28     ` Jon Smirl
2006-06-06  5:55       ` Martin Langhoff
2006-06-06 15:13         ` Jon Smirl
2006-06-06 19:57           ` Martin Langhoff
2006-06-07  0:12             ` Keith Packard
2006-06-07  0:40           ` Jon Smirl
2006-06-01 23:48 ` Linus Torvalds
2006-06-02  0:59   ` Jon Smirl
2006-06-02  1:11     ` Linus Torvalds
2006-06-02  6:40       ` Junio C Hamano
2006-06-02 15:53         ` Linus Torvalds
2006-06-02 16:00           ` Junio C Hamano
2006-06-02  4:14 ` Martin Langhoff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0606031631480.5498@g5.osdl.org \
    --to=torvalds@osdl.org \
    --cc=git@vger.kernel.org \
    --cc=jonsmirl@gmail.com \
    --cc=keithp@keithp.com \
    --cc=martin.langhoff@gmail.com \
    --cc=robin.rosenberg.lists@dewire.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).