Amending non-tip changesets

Pierre-Yves David pyd at fb.com
Fri Apr 11 17:29:19 UTC 2014


On 04/11/2014 01:00 PM, Colin Caughie wrote:
> On 4/11/2014 8:00 AM, Pierre-Yves David wrote:
>>
>> On 04/11/2014 07:58 AM, Colin Caughie wrote:
>>> 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.
>>
>> hg evolve is exactly meant for that. Can you elaborate on this merge 
>> thing? The result should have been the same as rebase.
>
> Been doing some more testing. I updated to the latest version of the 
> evolve extension (previously was on 6a67606e1c34 from March 2) and 
> tried on both Linux and Windows (previously just using Windows). I'm 
> using Mercurial 2.9.1. on both systems, and also tried with 2.9.2 on 
> Windows.
>
> On Linux it worked perfectly; "hg evolve -a" rebased all my unstable 
> changesets. ("hg evolve" on its own only transplanted the first one to 
> the top of my history which I found slightly counter-intuitive but 
> acceptable).

Sounds like you are a lucky winner of this bug 
https://bitbucket.org/marmoute/mutable-history/issue/35/abort-no-support-for-evolution-merge

Its interesting that is show on windows only in your case. There must be 
some window specific thing going one.

If you use the latest stable branch of evolve, you'll still have the bug 
but it will abort early instead of butchering your repo.

-- 
Pierre-Yves David



More information about the Evolve-testers mailing list