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:
> \ \
> 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
> 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