Re: hgmq vs. StGIT

From: Chris Mason <mason@suse.com>
Date: Nov 1, 2005, 18:13 UTC
Message-ID: <20051101181352.GD26847@watt.suse.com>
In-Reply-To: <b0943d9e0511010918ob2dbcfcv@mail.gmail.com>

On Tue, Nov 01, 2005 at 05:18:49PM +0000, Catalin Marinas wrote:

Show 10 quoted lines

> On 01/11/05, Chris Mason <mason@suse.com> wrote:
> 
> That's true, but you can use a 'git tag' command to mark the whole
> stack as something useful and this would include the state of all the
> patches on the stack. This would be a whole stack history, not
> individual patch history. Maybe we should implement this as well (or
> maybe only this).
> 
> Anyway, I wasn't sure that's the right implementation and that's why I
> didn't include Chuck's patch yet.

I would suggest just putting the .git/patches directory under revision control. If you make it a head in git and then add helper functions so that common operations are easy to do, you won't be reimplementing the whole SCM wheel just for patches.

For example:

stg commit-patch-tree:
    does git-write-tree and git-commit-tree on .git/patches

stg checkout-patches sha1:
    updates .git/patches to a given patch commit

stg diff-patches [-p] [-f]:
    by default this does the same as git-diff-tree
    -p, read the patch commit objects and diff the patch files
    -f, read the patch commit objects and diff the source files
   
The command names could be better, but the idea is to make commits that
change the state of your patch tree.  Later on, you'll be able to find the
one commit where you added 6 patches, or the one commit where you
adapted the whole tree to some new feature.

More importantly, you can reuse gitk and all of the other history functionality in the SCM.

-chris