Re: hgmq vs. StGIT

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Nov 10, 2005, 16:20 UTC
Message-ID: <b0943d9e0511100820h2f10a011g@mail.gmail.com>
In-Reply-To: <20051109233255.GI30496@pasky.or.cz>

On 09/11/05, Petr Baudis <pasky@suse.cz> wrote:

Show 5 quoted lines

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

I agree with Pavel here :-)

Show 5 quoted lines

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

That's probably the simplest.

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

It happens to me to keep some patches popped which aren't really part of the stack (i.e. splitting a big patch, I still keep it in the unapplied patches to push it later and check what was left after splitting). From this point of view, (ii) would be better but with the drawback that you need to have a valid stack with all the patches pushed.

Show 7 quoted lines

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

(iii) is the most comprehensive method and, as Pavel said, we should record what patches were applied or not and reproduce them exactly when retrieving a different state.

Another big problem is the base of the stack, which can change. Would retrieving an old state of the stack also restore the old the base? I think it should and its up to the user to rebase it.

A simple way to partially achieve (iii) is to extend the existing 'branch' command to clone the whole series into a new one, including all the patches. The problem with this approach is that there is no temporal relation between branches.

How would you expect to switch between different states of the stack? As Chris Mason mentioned, once you start doing this people might ask for full SCM features (like diffs between revisions) where the objects are stack states. This would complicate StGIT quite a lot.

-- Catalin