1. 19
  1.  

  2. 7

    One really cool feature is the new absorb extension, which is helpful when revising a feature branch during code review. If someone gives you a bunch of code review comments and you go in and edit the code to reflect the comments, you just need to say “hg absorb” afterwards and it will automatically figure out which commits in your feature branch to edit, apply the changes, and automatically handle all the rebasing that needs to happen under the hood to accomplish this. It’s basically “hg histedit” on steroids for a really common post code review workflow.

    1. 4

      Rebase gets new –stop flag to stop interrupted rebase without discarding the already rebased changes.

      That’s really nice for ease of mind. It takes the pressure off conflicted rebases, because it turns ‘I have to finish the rebase in one go’ into ‘I can stop the rebase, and continue it later’. Only possible thanks to the Evolve extension, I believe! Many thanks everybody who made this possible, and Pierre-Yves David in particular.

      I’ve had a quick go at trying out this feature, and below is what it looks like in practice, and how the workflow went. For my fellow curious people <3.

      o    17 tip -- Sietse -- 2570f7a312d4
      |  _ conflict branch b: append Alpha bravo charlie
      | @    26 -- Sietse -- 1dfe2b6bf0dd
      | |  _ conflict branch b: append Delta echo foxtrot
      | x    25 -- Sietse -- ee1969070651
      | |  _ conflict branch b: append Alpha bravo charlie
      o |    14 -- Sietse -- df20a364d54f
      | |  _ conflict branch a: append Teun vuur gijs
      o |    13 -- Sietse -- 659582b3368e
      |/   _ conflict branch a: append Wim zus jet
      o    12 -- Sietse -- 163f02014dd7
      |  _ conflictme
      o    11 -- Sietse -- df6ebc3fc5d4
      |  _ random commit
      
      1. I created two branches with conflicting changes: branch a (commits 13 and 14) and branch b (commits 25 and 26). (NB: I have taken a slight liberty with the commit numbers: they were actually 15 and 16, but calling them 25 and 26 makes it easier to recognise them as a separate branch.)

      2. I then invoked hg rebase on commits 25&26, with destination atop 14. (hg rebase -r 25:: -d 14, FWIW)

      3. Mercurial prompted me to resolve a merge conflict moving commit 25 atop 14. I did so, and proceeded with hg rebase --continue (instead of an overloaded git commit command)

      4. Next I got a prompt to resolve a conflict moving 26 (the remaining commit of my source branch) atop 17 (the just-created rebased commit, the successor of the now-obsolete 25).

      5. I called hg rebase --stop. After all, I had just had an exhausting time fixing conflicts to rebase commit 25, and I needed some time away before I wanted to take on commit 26.

           $ hg rebase --stop
           1 new orphan changesets
        
      6. The result is the commit graph you see above. As you can see, commit 25 is obsolete: it has a successor. commit 26 is an orphan, atop a now obsolete commit. If I ever call hg evolve on 26, Evolve will know where to move it: 26 was atop 25, so it will be rebased atop 25’s successor: atop 17. I will then resolve that conflict, and complete the rebase.

      1. 2

        Using Mercurial is such a delight after having had to work with git every day. I never think about version control and all the arcane commands, I just do my work. I hope I never have to go back.