Re: hgmq vs. StGIT

[Petr Baudis <pasky@suse.cz>]

Dear diary, on Sat, Nov 05, 2005 at 09:23:33PM CET, I got a letter
where Catalin Marinas <catalin.marinas@gmail.com> said that...
> 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.

Yes, that would be nice to have as well (although in general I lean to
recording the whole stack now). Model scenario:

A night city, the snow slowly falling. Approaching the roofs covered in
white and illuminated by the yellow street lighting, dark windows - but
one dimly glowing, a computer screen inside. Close-up on a hacker:
$EDITOR opened, lost deep in hack mode, fingers dancing over the
keyboard.  Dreamy-monumental music in the background.

StGIT user, only part of the patches in stack, and the rest depends on
the one currently edited, and I want to record my work on this one.
I can either:

(i) Just keep per-patch history only.

(ii) Keep _both_ per-patch and per-stack history (since I don't want to
record the stack when I have to keep some patches out of it - the
history would look like randomly removing and adding tons of patches,
and jumping around would be difficult because of this too).

(iii) Keep per-patchlist history - do not actually record only our
current stack, but all the patches StGIT knows about. The patches
depending on the one currently being changed will not be in consistent
state, but that's tough. Actually, this seems to be the most viable
strategy. One question is whether to record if some patch is actually
applied right now or not (I'd say don't record it since you again have
the "bouncing problem" otherwise).

Ideas?

> 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.

Yes, now let's sequence the tags... ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.