Re: Requirements for integrating a new git subcommand

["Eric S. Raymond" <esr@thyrsus.com>]

Michael J Gruber <git@drmicha.warpmail.net>:
> Regarding git-weave, I'm wondering (without having looked at the code)
> how this relates to git-archiv and git-fast-import/export, i.e. how much
> this leverages existing infrastructure rather than reinventing the
> wheel. Do your "trees" correspond to a "git tree"?

The unravel operation of git-weave is something like running
git-archive on every revision and saving the results in
sequentially-named directories, except that it also produces a
metadata file that allows the operation to be inverted.
So it is strictly more powerful.

The weave operation could be implemented using git fast-import, which
I am quite intimately familiar with from having written reposurgeon.
Functionally, the difference is that it would be a PITA to patch a
fast-import stream to insert or modify or remove revisions in the
middle, because the content of any given revision is in blobs that can
stretch arbitrarily far back from its commit and are shared with
other revisions.  With git-weave tree-sequences these operations
are easy and safe.

> Again, without having looked at the code, it seems to me that exploding
> blob and tree objects might give you a structure not much unlike
> weave's, and your instruction sheet resembles that of fast-import quite
> a bit (plus date fill-in etc.).

The weave log resembles an import stream, yes - that's because they
have to capture the same data ontology.  One major difference is that weave
logs are designed to be generated and edited by humans.
 
> One could even dream about implementing this as a remote helper instead...

What is a "remote helper" in this context?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>