Re: hgmq vs. StGIT

From: Chris Mason <mason@suse.com>
Date: Nov 1, 2005, 17:59 UTC
Message-ID: <20051101175905.GC26847@watt.suse.com>
In-Reply-To: <b0943d9e0511010929u22b33e4el@mail.gmail.com>

On Tue, Nov 01, 2005 at 05:29:19PM +0000, Catalin Marinas wrote:

Show 13 quoted lines

> On 01/11/05, Chris Mason <mason@suse.com> wrote:
> > mq is closer to quilt.  The patches are stored as patches, and hg qpush
> > is very similar to importing a patch.  This means metadata must be
> > stored at the top of the patch in some form the import code can
> > understand (it tries to be smart about this).
> 
> The problem with this is allowing people to modify the patch directly
> (with vi). This would make it difficult to do a three-way merge
> without either losing the direct changes or simply failing to apply a
> modified patch to its old base (I thought about using patches as an
> optimisation but after some benchmarking found that "git-diff-tree |
> git-apply" is fast enough and most of the time when pushing is
> calculating the sha1 hash of the resulting index file).

The three way merge is still possible even if someone hand edits the patch. For a three way merge, you just need to know the parent revision of the change you want to merge. parent can mean the revision in the repository that precedes this patch (mq stores this information, just not in the patch), or it can mean any revision where the patch applies cleanly.

Both approaches (mq vs stgit) have advantages...you can get roughly the same functionality either way.

-chris