Re: hgmq vs. StGIT

[Chris Mason <mason@suse.com>]

On Tue, Nov 01, 2005 at 05:18:49PM +0000, Catalin Marinas wrote:
> 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