Thread (24 messages) flat view 24 messages, 10 authors, 2016-06-15

Re: hgmq vs. StGIT

From: Catalin Marinas <hidden>
Date: 2016-06-15 22:42:10

Sorry for the delay in replying.

On 02/11/05, Chris Mason [off-list ref] 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.
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help