Re: [PATCH] Add a birdview-on-the-source-code section to the user manual

From: Daniel Barkalow <barkalow@iabervon.org>
Date: May 9, 2007, 20:45 UTC
Message-ID: <Pine.LNX.4.64.0705091625200.18541@iabervon.org>
In-Reply-To: <Pine.LNX.4.64.0705092208230.4167@racer.site>

On Wed, 9 May 2007, Johannes Schindelin wrote:

Show 14 quoted lines

> 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.

Show 5 quoted lines

> 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*