Re: hgmq vs. StGIT

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Nov 5, 2005, 20:23 UTC
Message-ID: <b0943d9e0511051223g74c2be43h@mail.gmail.com>
In-Reply-To: <20051102154108.GM26847@watt.suse.com>

Sorry for the delay in replying.

On 02/11/05, Chris Mason <mason@suse.com> wrote:

> I think we're talking past each other a little, partially because
> I'm not sure exactly what features you want from revision control on the
> patches.

That's unclear for me too :-). I would like to have a way of checking the changes to individual patches, just to be able to go back if some changes broke it. It's also useful to have some kind of revision control for the whole stack, but this can be achieved with tags at the moment. What I usually do is export the series when I'm happy with it and keep that directory safe. I could add revision control for the directory containing the exported series but this would be somehow outside StGIT.

Show 5 quoted lines

> But, my suggestion is to remember that once you add some sort of
> revision control, people are going to want all of the features they are
> used to with git/hg/their favorite SCM.  You'll probably get better
> results if you patch git to your needs then if you try to reimplement
> things all over again.

That's true. I think that people who want a full revision control of the patches should rather use separate branches instead of stacked patches. It's indeed more convenient to be able to add or remove features with push/pop but providing yet another SCM layer on top of these would make the tool hard to understand (and maybe make Quilt fans run away from it).

The current StGIT features are enough for my needs but I'll accept/implement new features based on others' requirements.

BTW, the latest StGIT snapshot has support for a 'patches' command which shows the patches modifying a file or set of files (that's because I needed this feature recently).

-- Catalin