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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html