Re: Requirements for integrating a new git subcommand

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

Junio C Hamano <gitster@pobox.com>:
> "Eric S. Raymond" <esr@thyrsus.com> writes:
> 
> > While the weave operation can build a commit graph with any structure
> > desired, an important restriction of the inverse (unraveling)
> > operation is that it operates on *master branches only*. The unravel
> > operation discards non-master-branch content, emitting a warning 
> > to standard error when it has to do so.
> 
> Imagine that I have a simple four-commit diamond:
> 
>     I---A
>      \   \
>       B---M
> 
> where Amy and Bob forked the initial commit made by Ian and created
> one commit each, and their branches were merged into one 'master'
> branch by a merge commit made by Mac.  How many state snapshots will
> I see when I ask you to unravel this?  Three, or four?

You will see four tree states.  I have managed to remove the
master-branch-only restriction.

> As to the procedural stuff, I think others have sufficiently
> answered already.  If I may add something, a new stuff typically
> start its life in contrib/ before it proves to be useful.

Thank you, I have submitted a documentation patch which folds
in the on-list discussion.

As a separate point...are you requesting that I submit my integration
patch to drop git-weave in contrib?  If so, I will of course comply.

But I will point out that git-weave is not a half-thought out
experiment; it is fully documented and has a functional test.  The
case for its usefulness is bolstered by one previous contrib script,
which the author has agreed to retire in favor of git-weave.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>