On Wed, 9 May 2007, Johannes Schindelin wrote: > Let me explain it in this way: > > If you parse a number, passed to a program, with strtol(argv[1], NULL, 0) > you would expect something like this on an Intel processor: > > Input 0x1234 -> memory 0x34 0x12 0x00 0x00. > > On a big endian machine, you'd expect 0x00 0x00 0x12 0x34. > > That is what endianness means. > > If you tell Git that it should look for commit e83c6516..., it will store > the sha1 as 0xe8 0x3c 0x65 0x16 ... in memory, no matter which > endianness the processor has. But it would be really weird to get 0x90 0xf2 0x4a 0x60 ... 0x16 0x65 0x3c 0xe8 unless you've got a 160-bit little-endian processor. That would be as strange as having "Test" stored as 0x74 0x73 0x65 0x54, I think. > Which was positively confusing for me, since I automatically searched for > the sequence 0x90 0xf2 0x4a 0x60 ... (which is the tail of that hash). > > But if all this sounds too confusing, I agree to delete the > "(big-endian)". If it confused you, there should be something there. Maybe "(in order)" or something else implying that the underlying type is an octet sequence, rather than a 160-bit integer? -Daniel *This .sig left intentionally blank* - 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
