[PATCH] histedit: add support for exec/x command to histedit (issue4036)

[Durham Goode]

On 9/9/15 9:04 AM, liscju wrote:
> # HG changeset patch
> # User liscju <piotr.listkiewicz at gmail.com>
> # Date 1441363832 -7200
> #      Fri Sep 04 12:50:32 2015 +0200
> # Node ID 4ee403abb436e0f177dc149be13a598a61db14b8
> # Parent  fd9b1262f0e4fbcec1f66f01839bf3d4ee4cff59
> histedit: add support for exec/x command to histedit (issue4036)
>
> Point of this command is to be able to do some automatic munging
> on one or several commits in a series.
>
> The basic contract is that it receives a clean working copy and is
> expected to leave a clean working copy if it exits 0. If either
> the command leaves the working copy dirty, or it exits non-zero,
> the histedit stops to give opportunity for user intervention.
>
> Behavior is undefined if it updates to some completely unrelated
> portion of history.
>
> Exec command functionality is implemented in exec_ class. It is
> overriding fromrule class method to deal with initializing
> object in different way than other histeditactions. It takes
> state and cmd instead of state and node id of next changeset
> action to perform on.
>
> Run method of exec_ class at first updates to parent of current
> changeset,apply it and commit to obtain copy of current changeset
> in current directory. It is done to let cmd ammend to this changeset
> and correctly perform changing history containing this changeset.
>
> In run method locks are released right before running command to
> allow running hg commands inside it.
>
Cool.  We did something similar over in 
https://bitbucket.org/facebook/hg-experimental/src/fbf23b3f96bade5986121a7c57d7400585d75f54/fbhistedit.py?at=default 
and luckily the implementations look very similar.  I'll take a deeper 
look at your patch later today hopefully to see how they differ.