Allow user to keep working copy changes after undo, mimicking unamend and
uncommit behavior. As discussed at the team lunch, this allows undo to remain
ignorant of what command the user has run while conforming to user expectations.
In the future this could be done in a smarter way where we properly restore hg
status dynamically.
Details
- Reviewers
quark - Group Reviewers
Restricted Project - Commits
- rFBHGX720575ccec6b: undo: add --keep to maintian working copy changes
Diff Detail
- Repository
- rFBHGX Facebook Mercurial Extensions
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Event Timeline
hgext3rd/undo.py | ||
---|---|---|
403–404 | Yes. The major downside is that it makes redo non-trivial for the user as they need to clean up the working copy beforehand. There's also potentially some performance cost to --keep in the case of a large working copy. |
hgext3rd/undo.py | ||
---|---|---|
508 | Why is the obsolete.createmarkers vs revealcommits difference? I think the behavior should be the same regardless. |
hgext3rd/undo.py | ||
---|---|---|
508 | Fundamentally, its because there isn't a connection between two (arbitrary) working copy parents. With the --keep flag though, the user is heavily implying that there is a very strong connection between the two. Granted, the user can use --keep for really "weird" operations, but I think the obs marker is allowed to reflect that. That being said, I can remove line 491 (revealcommits), since update will not fail to hidden commit, and that commit should be revealed later anyway. |
hgext3rd/undo.py | ||
---|---|---|
508 | I noticed these lines are removed in the next diff. So the end result looks good to me. I think line 491 is still necessary since visibility and obsolesce are different. We need to make the changeset "not obsoleted", hence the revive part. With fbamend, update could "unhide" the commit, but it won't "unobsolete" a commit. |
specifically :)