Re: hgmq vs. StGIT

[Chuck Lever <cel@citi.umich.edu>]

[-- Attachment #1: Type: text/plain, Size: 4256 bytes --]

Catalin Marinas wrote:
> On 01/11/05, Petr Baudis <pasky@suse.cz> wrote:
> 
>>Did anyone do any current detailed comparison between hg mq and StGIT?
> 
> 
> Not AFAIK. I looked a bit at mq but didn't have time to play with it.
> 
> 
>>I'm very happy with StGIT, modulo few UI gripes I'm still not getting
>>around to fix, 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.
> 
> 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'm open to other suggestions as well. Otherwise, Chuck's patch should
> do the job.

if there is interest i can post what i have.  unfortunately there's some 
other stuff in front of it so i don't think it will apply directly to 
catalin's stgit without some futzing.  in lieu of that, here's a command 
synopsis:

[cel@seattle ~]$ stg revisions -h
usage: stg revisions [options] [patch-name]

Display the change history of a patch or revert a patch to a previous
commit.  By itself, the command will display all committed changes,
ordered by date, of a patch.  Each committed change is listed with a
numeric label.  The label can be used with the --patch or --diff options
to examine specific changes in detail.  The --revert option can revert
a patch to any previous version.

options:
   --commit=commit-label
                         show the commit details of the specified commit
   --diff=commit-label   show changes between the specified commit and 
the next
   --file=<file name>    show changes made to a specific file
   --patch=commit-label  show the state of patch-name at the specified 
commit
   --revert=commit-label
                         revert the patch to the specified previous commit
   -h, --help            show this help message and exit
[cel@seattle ~]$

and some usage examples:

[cel@seattle main]$ stg revisions
Previous revisions of patch "revisions-command":
   0:    Sat Oct 1 21:54:43 2005 -0400
   1:    Sat Oct 1 21:58:45 2005 -0400
   2:    Sat Oct 1 22:13:27 2005 -0400
   3:    Sat Oct 1 22:55:28 2005 -0400
   4:    Sat Oct 1 23:02:22 2005 -0400

  ... snipped ...

   86:   Mon Oct 31 14:19:25 2005 -0500
   87:   Mon Oct 31 14:22:00 2005 -0500
   88:   Mon Oct 31 14:23:40 2005 -0500
   89:   Mon Oct 31 14:24:39 2005 -0500
   90:   Mon Oct 31 14:27:34 2005 -0500
[cel@seattle main]$

an entry is added to this list automatically after every operation that 
does a "refresh".

the idea is to expose and manipulate the change history of a patch 
without having to use cumbersome sha1 hash values.

without options, "stg revisions" shows a list of changes to a patch, by 
date.  each change has a label (just a number) which you can use to 
generate diffs and such.  to wit:

    stg revisions --patch=45

would show a diff between the previous patch, and the state of the patch 
at change 45.

    stg revisions --diff=45

would show a diff between change 45 and change 44.

    stg revisions --commit=45

would show pretty-printed commit information for change 45.

    stg revisions --revert=45

would revert the patch back to the way it was in change 45.  notably, 
you don't throw away changes 46 through 90 when you do this.  a new 
change is added which changes the state of the patch to the way it was 
in change 45.  (well, that's how it's supposed to work, anyway).

i'm interested to hear what folks on the list think of the idea.

[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 439 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Linux NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763-4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668-1089
x-mozilla-html:FALSE
url:http://www.monkey.org/~cel/
version:2.1
end:vcard