This is an archive of the discontinued Mercurial Phabricator instance.

histedit: add move histedit action
AbandonedPublic

Authored by mbthomas on Sep 26 2017, 6:14 AM.

Details

Reviewers
ryanmce
Group Reviewers
hg-reviewers
Summary

Add a new histedit action: move. This allows moving of changesets from
outside of the history that is being edited, using the node hash of the other
changeset.

The changeset is copied to the location in the edited history, and the other
changeset is removed from the repository if possible.

If removing the other changeset is not possible (for example, if removing
the changeset would create an orphaned revision, and this is not allowed)
then the move becomes a copy and a warning is emitted.

Diff Detail

Repository
rHG Mercurial
Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

mbthomas created this revision.Sep 26 2017, 6:14 AM
ryanmce requested changes to this revision.Sep 26 2017, 7:53 AM
ryanmce added a subscriber: ryanmce.

I think we need to think about this one a bit more.

hgext/histedit.py
861

hide is really only FB-internal naming. In regular/core hg, this would still likely be a strip.

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.
This revision now requires changes to proceed.Sep 26 2017, 7:53 AM
mbthomas added inline comments.Sep 26 2017, 1:14 PM
hgext/histedit.py
867–868

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

quark added a subscriber: quark.Sep 26 2017, 1:33 PM
quark added inline comments.
hgext/histedit.py
861

Strictly speaking, it is "rebase", which is not 100% equal to graft + hide. The latter does not create an obsmarker.

867–868

How about just letting pick accept external commits? We can gate the feature by a config option if it looks risky.

880

error.Abort may be more appropriate. ParseError is more about a syntax error (ex. having [^0-9a-f] in commit hash).

I'm thinking now that maybe we don't want move at all. If someone does want to move a commit using histedit, they can copy it in and then strip/hide the old commit. At the moment there is no way for histedit to affect commits outside the history range that it is editing, and I think that's a good thing.

quark added a comment.Oct 5 2017, 11:56 PM

I'm thinking now that maybe we don't want move at all. If someone does want to move a commit using histedit, they can copy it in and then strip/hide the old commit. At the moment there is no way for histedit to affect commits outside the history range that it is editing, and I think that's a good thing.

With the current design, copy X to Y then prune (which could be different from "hide", I think our "hide" implementation is still subject to change) X will not create an obsmarker from X to Y. That is the reason why move is needed. That's also mentioned in IRC:

Sep 25 11:14:00 <durin42>	I think they probably both need to exist
Sep 25 11:14:05 <durin42>	since move should record an obsolete marker

It might be possible to make things smarter so copy X to Y then hide X is equivalent to move X to Y. But the existing code does not support that yet.

mbthomas abandoned this revision.Oct 12 2017, 5:10 AM