[PATCH 4 of 5 V2] histedit: add execute function (issue4036)

[Olle]

On Thu, Mar 6, 2014 at 7:42 PM, Augie Fackler <raf at durin42.com> wrote:

>
> On Mar 6, 2014, at 1:14 PM, David Soria Parra <dsp at experimentalworks.net>
> wrote:
>
> Augie Fackler <raf at durin42.com> writes:
>
>  On Thu, Mar 06, 2014 at 12:26:17PM +0100, Olle Lundberg wrote:
>
> # HG changeset patch
> # User Olle Lundberg <geek at nerd.sh>
> # Date 1394067184 -3600
> #      Thu Mar 06 01:53:04 2014 +0100
> # Node ID 655a8eecb29f6e58d56eb480e0b871139f0f134e
> # Parent  ab2d2ac49a0293653398995ef2de73f31485341a
> histedit: add execute function (issue4036)
>
>
> queueing 1 and 3 for now, I want to talk about this more. I thought
> the only common use case for this was to run the same command over all
> revisions in a series?
>
> If that's still true, I'd much rather have a 'hg filterevs' command
> that took a revset. This feels very awkward to me.
>
>
> A common usecase is to go back to a revision, fix it up and then only
> send this very revision to an upstream review tool like reviewboard &
> co, so not over a all revisions in a series.
>
>
> given:
>
> a - b - c - d - e
>
> 'hg filterrevs c::d'
>
> which would perform the specified operation(s) on c and d, and then do the
> rebase/graft/whatever for e. Does that seem reasonable?
>

It seems reasonable, it might be confusing for git refugees though. Not
that we try to cater everything for them. Just a heads up. I'm up for
changing it, if filterrevs are prefered. But then we'll get two commands
(histedit and filterrecs) doing more or less the same thing, history
editing, except one is automatic. Don't know how if that will be confusing.

>
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>
>


-- 
Olle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20140306/6156bceb/attachment.html>