Re: hgmq vs. StGIT

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

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

quoted

and the fact that I cannot version my changes to patches
- this is one advantage of having quilt stuff tracked by GIT, I think,
but that feels ugly.

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.

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

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