This has never worked usefully:
- it can't undo a completely unwanted merge, as it leaves the merge in the DAG
- it can't undo a faulty merge as that means doing a merge correctly,
not simply reverting to one or the other parent
Both of these kinds of merge also require coordinated action among
developers to avoid the bad merge continuing to affect future merges,
so we should stop pretending that backout is of any help here.
As backing out a merge now requires a hidden option, it can't be done
by accident, but will continue to 'work' for anyone who's already
dependent on --parent for some unknown reason.
This is handy if hgext.foo exists but has a bogus "import blah":
previously we just discarded the "No module named blah" error. Now at
least you can see it with --debug. Not perfect, but better than
nothing.
Now 'rollback' after 'import' is less surprising: it rolls back all of
the imported changesets, not just the last one. As an extra added
benefit, you don't need 'rollback -f' after 'import --bypass', which
was an undesired side effect of fixing issue2998 (f9f52d71c33b)..
Note that this is a different take on issue963, which complained that
rollback after importing multiple patches returned the working dir
parent to the starting point, not to the second-last patch applied.
Since we now rollback the entire import, returning the working dir to
the starting point is entirely logical. So this change also undoes
b12d79024900, the fix to issue963, and updates its tests accordingly.
Bottom line: rollback after import was weird before issue963,
understandable since the fix for issue963, and even better now.
This only matters when using the deprecated --base option, and
combining --base with a patch on stdin makes no sense. But it's such
an obvious bug and easy fix that I couldn't pass it by.
The old code printed (with ui.status()) the changeset ID created by
patch N after committing patch N+1, e.g.
applying patch1
applying patch2
applied 1d4bd90af0e4
where 1d4bd90af0e4 is the changeset ID resulting from patch1. That's
just weird. It's also inconsistent: we only reported the changeset ID
when applying >1 patches. And it's inconsistent with 'commit', which
only tells you the new changeset ID in verbose mode. Finally, the
existing code was I18N-hostile, since it concatenated translated
strings.
The new way is to print the just-created changeset ID with ui.note()
immediately after committing it. It also clarifies what the user
message is for easier I18N.
You can get into trouble if you commit, update back to an older
changeset, and then rollback. The update removes your valuable changes
from the working dir, then rollback removes them history. Oops: you've
just irretrievably lost data running nothing but core Mercurial
commands. (More subtly: rollback from a shared clone that was already
at an older changeset -- no update required, just rollback from the
wrong directory.)
The fix assumes that only "commit" transactions have irreplaceable
data, and allows rolling back non-commit transactions as always. But
when rolling back a commit, check that the working dir is checked out
to tip, i.e. the changeset we're about to destroy. If not, abort. You
can get back the old (dangerous) behaviour with --force.
