Junio C Hamano <gitster@xxxxxxxxx>: > "Eric S. Raymond" <esr@xxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html