Amending non-tip changesets

Colin Caughie c.caughie at gmail.com
Fri Apr 11 14:58:14 UTC 2014


I've recently started using the evolve extension as part of my daily 
workflow, replacing mq. So far my experience has been excellent; it 
seems to work very well and wasn't hard to pick up. I really like 
knowing that if I mess up I can always get back to where I was (even if 
it still sometimes takes a bit of thinking to figure out how).

There is one part of my workflow that I haven't quite figured out how to 
optimize yet, I wonder if any of you have any suggestions. It relates to 
our code review process, which I discussed last month on the Mercurial 
list (the "ReviewBoard and Mercurial" discussion). Our mq-based process 
goes like this:

1. Commit changes as an mq patch
2. Post a review
3. Continue working, creating new mq patches as necessary
4. When you get review feedback, pop the later patches, make the 
required changes to the patch under review and qrefresh
5. Post a diff update based on the amended patch, e.g. using "hg 
postreview -e"
etc.
6. qpush the later patches and continue working

Steps 4-6 are the interesting ones. I know I can do:

4. After feedback, "hg update" to the the changeset that needs modified, 
make the required changes and run "hg amend"
5. Post a diff update based on the amended patch
6. Rebase the newer changesets using "hg rebase <rev>", where <rev> is 
the first changeset after the one being amended
7. "hg update" to get back to tip.

This works, but it would be nice to be able to do that "automatically", 
i.e. without having to find the revision number of the changeset to be 
rebased. Like maybe an "hg rebase --unstable" option?

I did try "hg evolve -a" but that did something a bit weird; it looked 
like it *merged* the unstable changesets with my amended one which made 
the graph look a lot more complicated than it needed to be.

Thanks,
Colin




More information about the Evolve-testers mailing list