Re: full kernel history, in patchset format

From: Linus Torvalds <torvalds@osdl.org>
Date: Apr 16, 2005, 18:44 UTC
Message-ID: <Pine.LNX.4.58.0504161135480.7211@ppc970.osdl.org>
In-Reply-To: <1113679421.28612.16.camel@tglx.tec.linutronix.de>

On Sat, 16 Apr 2005, Thomas Gleixner wrote:

Show 7 quoted lines

> 
> One remark on the tree blob storage format. 
> The binary storage of the sha1sum of the refered object is a PITA for
> scripting. 
> Converting the ASCII -> binary for the sha1sum comparision should not
> take much longer than the binary -> ASCII conversion for the file
> reference. Can this be changed ?

I'd really rather not. Why don't you just use "ls-tree" for scripting? That's why it exists in the first place.

It might make sense to have some simple selection capabilities built into ls-tree (ie "ls-tree --match drivers/char/ -z <treesha1>" to get just a subtree out), but that depends entirely on how you end up using it.

The fact is, there should _never_ any reason to look at the objects themselves directly. "cat-file" is a debugging aid, it shouldn't be scripted (with the possible exception of "cat-file blob xxxx" to just extract the blob contents, since that object doesn't have any internal structure).

That level of abstraction ("we never look directly at the objects") is what allows us to change the object structure later. For example, we already changed the "commit" date thing once, and the tree object has obviously evolved a bit, and if we ever change the hash, the objects will change too, but if you always just script them using nice helper tools, you won't ever need to _care_. And that's how it should be.

If there's a tool missing, holler. THAT is the part I've been trying to write: all the plumbing so that you _can_ script the thing sanely, and not worry about how objects are created and worked with.

For example, that "index" file format likely _will_ change. I ended up doing the new "stage" flags in a way that kept the index file compatible with old ones, but I did that mainly because it also happened to be the easiest way to enforce the rule I wanted to enforce (ie the "stage" really _is_ a part of the filename from a "compare filenames" standpoint, in order to make sure that the stages are always ordered).

So if the index file change hadn't had that property, I'd have just said "I'll change the format", and anybody who tried to parse the index file would have been _broken_.

		Linus