Amending non-tip changesets

[Olle]

On Fri, Apr 11, 2014 at 7:29 PM, Pierre-Yves David <pyd at fb.com> wrote:

>
> 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.
>
I have done som investigations into this bug and came to the conclusion
that it is a solely windows based bug. Not reproducible on linux (at least
with the steps posted in the bug tracker).

>
> 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
>
> _______________________________________________
> Evolve-testers mailing list
> Evolve-testers at selenic.com
> http://selenic.com/mailman/listinfo/evolve-testers
>



-- 
Olle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-evolve-testers/attachments/20140412/e67ff0f3/attachment-0002.html>