Re: hgmq vs. StGIT

On 01/11/05, Petr Baudis [off-list ref] wrote:

Dear diary, on Tue, Nov 01, 2005 at 10:23:55AM CET, I got a letter
where Catalin Marinas [off-list ref] told me that...

quoted

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.

The patches need to be chained so a top patch would also refer to the
previously applied patches since they are its base. Anyway, I don't
like adding too many files to the refs/heads directory.

quoted

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.

The refresh -n should be the default and maybe just specifying an
option when you want to add a comment to that commit. But, by mutating
the temporary commit, wouldn't this mean that you lose the refresh
history?

Anyway, "freeze" is confusing. Perhaps "snapshot" if anything...

You are right.

--
Catalin