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