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

[Olle]

On Sat, Mar 8, 2014 at 10:06 PM, Sean Farley
<sean.michael.farley at gmail.com>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.
>
> I want to chime in here before this gets too off-topic but I am against
> having another command that edits history. We already have a command
> that does history editing called histedit.
>
> I think the talk of this feature should be moving in the direction of
> "how can we allow better / finer control over 'hg edit --continue'"?
> Currently, we have no way to change or keep the commit message without
> human intervention.
>
> I would like to see something done that allows the following:
>
> hg histedit 'only(foo)'
> <edit an earlier commit>
> <send the changes to test server>
> hg histedit --cont (with the commit message kept the same but appended
> with the returned result from the server)
>
> Having a new command 'filterrevs' forces me to do my changes, generate a
> new hash, run filterrevs, then generate another hash. This is
> unnecessary and becomes annoying when having many commits on top of my
> earlier commit that I have to re-graft twice (expensive for large
> repos).
>
> Why is there such opposition to adding an exec flag to histedit?
>

I actually prefer to keep them in the same command, it seems more logical
to keep the same functionality grouped together. But there seems to be some
strong preference for adding a new command. Anyway, will probably try to
massage what I have to an out of tree extension, implementing a command
called histfilter (re: IRC with mpm and others), that uses som logic from
histedit and then try to get some audience to try it out.

(In hindsight: this bug probably shouldn't have been marked as easy)



-- 
Olle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20140310/9746b758/attachment.html>