Re: Requirements for integrating a new git subcommand

From: Eric S. Raymond <esr@thyrsus.com>
Date: Nov 23, 2012, 15:53 UTC
Message-ID: <20121123155306.GB20097@thyrsus.com>
In-Reply-To: <50AF3E36.4080800@drmicha.warpmail.net>

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>