Junio C Hamano <gits...@pobox.com>:
> "Eric S. Raymond" <e...@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>
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to