Re: full kernel history, in patchset format

JCH> I have been cooking this idea before I dove into the merge stuff JCH> and did not have time to implement it myself (Hint Hint), but I JCH> think something along the following lines would work nicely:

It should be fairly obvious from the context what I meant to say, but in case somebody gets confused by my inaccurate description of small details (or, before somebody nitpicks ;-), I'd add some clarifications and corrections.

JCH> * Run diff-tree between neighboring commits [*1*] to find out JCH> the set of blobs that are "related". Extract those related JCH> blobs and run "diff" [*2*] between them to see if it produces JCH> a patch smaller than the whole thing when compressed. If JCH> diff+patch is a win, then we do not have to transmit the blob JCH> that we could reproduce by sending the diff. Note that fact.

I talked only about blobs here, but I really mean all types: commits, trees and blobs here. Nothing prevents us from extracting the raw data for trees and commits and run diff between them. We can use cat-file to do that today.

What we do not have is the reverse of "$ cat-file type >rawdata" (i.e. "$ write-file type <rawdata"), but that is trivial to write. The raw data for related tree objects should delta well. I do not think it is worth the effort to attempt delta for commit objects. Anything that git-archive-tar decides not to send in diff+patch form, be it blob or tree or commit, should be noted here, not just blob as my previous message incorrectly implies.

JCH> Given the above, the operation of git-archive-patch is also JCH> quite obvious. Extract the "diff package" tarball into the JCH> objects/ directory that has (at least) the full Bn, uncompress JCH> the patch file part, and run patch on it.

Of course after you ran patch to reproduce the raw data for the blob or tree, we need the reverse of cat-file to register such data under object/ hierarchy.