Glen Choo <chooglen@xxxxxxxxxx> writes: >> The existing explanation starts with "32-bit mode, >> split into (high to low bits)", followed by "4-bit object type", as >> if the "4-bit object type" occupies bits 29-32, which is not quite >> what we want to say. > > If I am understanding you correctly (which I'm not sure, since I am > honestly clueless about bit numbering and big endianness and whatnot), > you're saying that highest 16 bits are zero, not the lowest? If so, then > I genuinely made that mistake, hah. > > (We're storing 16 bits as bigendian 32 bits, so they would occupy the > lower 16 bits, right..?) > > Perhaps something like this would be better. I took the "unused, must be > zero" phrasing from elsewhere in the doc. And if I am completely > off-base, feel free to patch it without waiting for my reroll if you > think that's easier. Whoops, this was meant to be a reply to https://lore.kernel.org/git/xmqqmt5yy08d.fsf@gitster.g. That's what I get for trying to write the In-Reply-To by hand.
