On Thu, 26 Apr 2007, Alexander Klink wrote: > > Same here (this is a MacBook Pro, for what it's worth, BTW). As said, I've > investigated this a bit further. The empty filename in new seems to come from > trying to read the wrong SHA1 file. If one outputs ce->sha1 before > void *new = read_sha1_file(ce->sha1, &type, size); > is called, one gets different output on Linux and Mac OS X. > For Seth's example, I get 5f34b0af07646aa529b5b005cde3a9559e606210 on Linux > and e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 on Mac OS X ... Well, 5f34b0af0 is the "bar.txt" blob, while e69de29b is the empty blob (Eg do [torvalds@woody git]$ echo -en "blob 7\0bar.txt" | sha1sum 5f34b0af07646aa529b5b005cde3a9559e606210 - [torvalds@woody git]$ echo -en "blob 0\0" | sha1sum e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 - to verify: git objects not only contain the data, but embed the object type and size too). So yeah, the printout matches the SHA1's, and the SHA1's are clearly not corrupted: they are just a sign of the fact that the data that was fed to whoever generated the SHA1's was simply different. But why git-svn would act differently under OS X than under Linux I have no idea. 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