[PATCH 04 of 11 RFC] histedit: add execute function (issue4187)

[David Soria Parra]

Olle Lundberg <olle.lundberg at gmail.com> writes:

> # HG changeset patch
> # User Olle Lundberg <geek at nerd.sh>
> # Date 1393978358 -3600
> #      Wed Mar 05 01:12:38 2014 +0100
> # Node ID 950c8d5b77e8d5eb610cbea159b7c02387bde211
> # Parent  125d473d0d3982c8a01c94acbcec350522d9555e
> histedit: add execute function (issue4187)
>
> 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-0,
> histedit aborts.
>
> diff --git a/hgext/histedit.py b/hgext/histedit.py
> --- a/hgext/histedit.py
> +++ b/hgext/histedit.py
> @@ -333,10 +333,23 @@
>      applychanges(ui, repo, oldctx, opts)
>      raise error.InterventionRequired(
>          _('Make changes as needed, you may commit or record as needed now.\n'
>            'When you are finished, run hg histedit --continue to resume.'))
>  
> +def execute(ui, repo, ctx, cmd, opts):
> +    hg.update(repo, ctx.node())
> +    rc = util.system(cmd)

We need to drop locks here and allow the command to execute a possible
repository changing command. A common case to use 'exec' is to amend
the previous commit by using an external command, e.g. patch. I know
this can lead to race conditions but I think an 'exec' user can be
tought to not shoot themselves in the food. Honestly without dropping
locks exec is fairly useless.