Re: hgmq vs. StGIT

> Dear diary, on Tue, Nov 01, 2005 at 10:23:55AM CET, I got a letter
> where Catalin Marinas <catalin.marinas@gmail.com> told me that...
> > That's not too far away. Chuck Lever has a patch (and there were some
> > other discussions in the past) for tracking the history of a patch.
> > Basically, there would be another commit object, not reachable from
> > HEAD but only via an StGIT command, which would chain all the versions
> > of a patch. You would be able to view them with gitk for example.
>
> Perhaps you could emulate the topical branches - one patch == one head.
> E.g. for patch foo-bar on branch 'master', you would create head
> master/foo-bar, etc.

> > My main issue was whether we should store every state resulted from a
> > refresh  or use a separate command (somebody suggested 'freeze') to
> > mark the states that should be preserved in the history. Chuck's patch
> > implements the first. The drawback is that a future 'stg prune'
> > command would not be able to remove the history and some states of the
> > patch might not be useful (there are times when I do a refresh only to
> > pop the patch and modify a different one, without any logical meaning
> > for the state of the patch).
>
> I'd prefer the snapshotting being done in refresh anyway. Perhaps you
> would be asked for log message when you refresh by default, but when you
> refresh -n or something, only a temporary commit would be created and
> next refresh would mutate it instead of creating another commit.