Re: mingw, windows, crlf/lf, and git

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2007-02-13 10:25:00
On Mon, 12 Feb 2007, Linus Torvalds wrote:
> 
> But it shouldn't be a problem. We'll always know which one matters: the 
> index case is always about pure stat information (and has no meaning 
> outside of that, really - after all, it's no different from st_mode etc, 
> and we actually keep it in a special binary format that is endian-safe!) 
> and the "real object" case is always about the *data* we use to compare 
> with.

In fact, for git-update-index, I think it's *literally* as easy as just 
changing "index_fd()" to convert the buffer on-the-fly as needed, before 
we actually call "write_sha1_file()" or "hash_sha1_file()".

So we'd just need to pass in the information about whether it's binary or 
not, and then do something like

	@@ -2091,6 +2091,10 @@ int index_fd(unsigned char *sha1, int fd, struct stat *st, int write_object, con
	 
	 	if (!type)
	 		type = blob_type;
	+#ifndef __UNIX__
	+	if (text && !strcmp(type, blob_type))
	+		convert_crlf_to_lf(&buf, &size);
	+#endif
	 	if (write_object)
	 		ret = write_sha1_file(buf, size, type, sha1);
	 	else

and that would take care of a lot of things (yeah, I'd not do it that way 
in practice, but really doesn't look that nasty - it's actually much 
nastier to have to look up the text/binary type in the first place).

Something similar looks to be true in diff generation. The core "compare 
two SHA1's at a time" doesn't need any changes, but the code that actually 
reads in the temporary file from disk obviously does. But even that is 
just _one_ point, afaik - diff_populate_filespec()":

	@@ -1362,6 +1362,10 @@ int diff_populate_filespec(struct diff_filespec *s, int size_only)
	 		if (fd < 0)
	 			goto err_empty;
	 		s->data = xmmap(NULL, s->size, PROT_READ, MAP_PRIVATE, fd, 0);
	+#ifndef __UNIX__
	+		if (text)
	+			convert_crlf_to_lf(&s->data, &s->size);
	+#endif
	 		close(fd);
	 		s->should_munmap = 1;
	 	}

(and again, that's not real code, it would also need to change the 
"should_munmap" flag to indicate the state of the _new_ "data" thing.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Tue Feb 13 10:32:21 2007

This archive was generated by hypermail 2.1.8 : 2007-02-13 10:35:15 EST