Anton Shestakov <av6@dwimlabs.net> [Mon, 02 Sep 2019 11:17:23 +0700] rev 4824
tests: demonstrate an orphan changeset cause "relocate node on top of itself"
See issue6097.
Anton Shestakov <av6@dwimlabs.net> [Fri, 30 Aug 2019 11:31:19 +0700] rev 4823
obslog: only indent the first chunk and chunks just after newlines (issue6175)
Anton Shestakov <av6@dwimlabs.net> [Fri, 30 Aug 2019 11:28:02 +0700] rev 4822
tests: demonstrate too many spaces in olog -p output with word-diff
Anton Shestakov <av6@dwimlabs.net> [Thu, 25 Jul 2019 18:37:16 +0800] rev 4821
rewind: add --keep flag that "doesn't modify working directory"
The actual logic is more complicated than the flag description, but it's
sufficiently similar to other --keep flags in action.
Unlike strip (or prune), rewind always needs to modify the working directory to
commit new revisions that "revive" old ones [1], see _revive_revision() (and
rewriteutil.rewrite()). Because of that we don't prevent rewind from modifying
wdir, but instead use hg.updaterepo() to update to the old changeset after the
"revival" process is complete. Then we rebuild the dirstate based on the commit
that rewind would update to without --keep.
Since dirstate.rebuild() doesn't restore status of some files (added, removed,
also copies and renames), we rely on cmdutil.revert(). It's a fairly crude
solution and needs to be removed when implementing the missing copy tracing
between oldctx and newctx (which are related only by obsolescence).
[1] IOW this means that --keep doesn't allow rewinding if wdir is dirty (unlike
e.g. strip).
Anton Shestakov <av6@dwimlabs.net> [Tue, 23 Jul 2019 18:05:40 +0800] rev 4820
tests: separate rewinding of merge commits, temporarily drop an error case
The error case will come back in the following commit, because it organically
fits there without the need of a separate working clone.
Raphaël Gomès <rgomes@octobus.net> [Wed, 07 Aug 2019 15:22:16 +0200] rev 4819
python3: add python3 beta support to the CHANGELOG