D817: histedit: add move histedit action

[mbthomas (Mark Thomas)]

mbthomas added inline comments.

INLINE COMMENTS

> ryanmce wrote in histedit.py:867-868
> Thinking about this more, I think this is pretty non-obvious to an average user.
> 
> In fact, the "move" versus "pick" difference is really unclear in general. Why must I "pick" something in the set, even if I'm actually moving it up or down, and "move" something from outside? If I "move" something up or down a slot, it's unclear why I want to use "pick" instead of "move" to an average user.
> 
> It seems to me that before we do this we should take a step back and talk about the end state we want to get to.
> 
> In my "idealized" world, histedit might have:
> 
> - `keep` (instead of "pick"), which I think is more clear. "pick" could still be a backwards-compatible name though (git's "pick" comes from "cherry-pick", and copying it to histedit seems like a mistake to me, in hindsight.
> - I like "copy" as-implemented in the previous patch. I think it's pretty clear and a nice four-letter name.
> - some kind of verb that allows me to take whatever commit, from wherever, and apply it where I am now with no unreasonable restrictions. Like a superset of "keep" and "move" (or whatever we name that). We could call it "grab" (?). `grab` is a term that we used for a while to "move" things from one point to another. It kind of evokes "graft" with it's prefix but is clearly different and implies taking it away from wherever it is.
> - (maybe) a "safe" way to move from somewhere else. I'm not sold on the "move" name the more I think about it because, desptie nicely being 4 letters, it doesn't really make clear to me how it is to be used.

Another four-letter candidate might be `take`.  I don't think `t` is taken as an abbreviation, either.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D817

To: mbthomas, #hg-reviewers, ryanmce
Cc: ryanmce, mercurial-devel