Junio C Hamano <[email protected]>:
> "Eric S. Raymond" <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
