Re: Requirements for integrating a new git subcommand

From: Eric S. Raymond <esr@thyrsus.com>
Date: Nov 26, 2012, 04:49 UTC
Message-ID: <20121126044922.GA14505@thyrsus.com>
In-Reply-To: <7vmwy5xe9n.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com>:

Show 18 quoted lines

> "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>