The recently introduced message was:
no unresolved files; you may continue your unfinished operation
This had three problems:
- looks a bit like an error message because it's not saying "we've
just resolved the last file"
- refers to "unfinished operation", which won't be the case with
"update" or "merge"
- introduces semicolons to error messages, which is stylistically
questionable
I've simplified this to:
no more unresolved files
In the future, if we want to prompt someone to continue a particular operation, we should use
a hint style:
no more unresolved files
(use 'hg graft --continue' to finish grafting)
When using resolve, users often have to consult with the output of |hg
resolve -l| to see if any unresolved files remain. This step is tedious
and adds overhead to resolving.
This patch will notify a user if there are no unresolved files remaining
after executing |hg resolve|::
no unresolved files; you may continue your unfinished operation
The patch stops short of telling the user exactly what command should be
executed to continue the unfinished operation. That is because this
information is not currently captured anywhere. This would make a
compelling follow-up feature.
In d87f1c1d18fa, be4d37a43992, 394118f2cf71, and 7594c2ea371e, new tests were
added that used TESTDIR instead of TESTTMP thereby leading to polluting the
working directory with these temporary files. Now, we use TESTTMP so that they
will be cleaned up properly.
Before this patch, manually edited commit message for "fold" command
in histedit-ing is never saved into ".hg/last-message.txt", because it
uses "localrepository.commitctx()" instead of
"localrepository.commit()": saving into ".hg/last-message.txt" is
executed only in the latter.
This patch saves manually edited commit message for "fold" command in
histedit-ing into ".hg/last-message.txt" just after user editing.
This is the simplest implementation to fix on stable. Editing and
saving commit message for memctx should be centralized into the
framework like "localrepository.commit()" with "editor" argument or so
in the future.
The tests contain a couple corner cases where workarounds are now
required. Strictly speaking, these are behavior regressions, but of an
extremely obscure and marginal sort. Commits or updates in the middle
of a histedit would have almost always been fairly serious user error.
When a file was renamed in the very first changeset being histedited,
the rename was not detected. Consider a history like this:
0 base: add a.txt
1 first: rename a.txt to b.txt
2 last: edit b.txt
When 1 and 2 are edited, copies.pathcopies(first, last) correctly
returns that nothing was renamed. We must instead use
copies.pathcopies(first, last) to detect the initial rename.
This is simpler than temporary file version. There some minor test
changes since commit messages are no longer modifed. There is still
some tests using --commands with a real file.
When "-" is specified as a command file, we read rules from stdin. Alter a
single test to demo the behavior, but most of them could benefit from this.
There is minor change in test output resulting from the fact we no
longer change log messages.
When all changes from the fold have been dropped, the --continue code was
confused. This changeset handles this case.
The test for this case existed but was broken.
One of the tests uses a python script to edit the histedit commands on
the fly. It was hard to read and likely to break. This is replaced by
a plain command file.
Doing so made me discover that the python script is incorrect. The
"+6" regexp never matched because the revision number is wrong.
This error is kept in the replacement for now. Fixing the histedit command
triggers a traceback in histedit.
A later changeset will fix the error and restore the intended test.
The default log displays a log of information that is useless for
histedit tests. Having a cleaner log help readability of those tests a
lot.
This does not change anything to the test semantic.
'export' is the official export format and used by patchbomb, but it would only
show date as a timestamp that most humans might find it hard to relate to. It
would be very convenient when reviewing a patch to be able to see what
timestamp the patch will end up with.
Mercurial has always used util.parsedate for parsing these headers. It can
handle 'all' date formats, so we could just as well use a readable one.
'export' will now use the format used by 'log' - which is the format described
as 'Unix date format' in the templating help. We assume that all parsers of '#
HG changeset patch'es can handle that.
Have histedit record the hex of the original changeset as already done by:
- graft
- commit --amend
- rebase
My main motivation for adding this is to prevent the creation of obsolescence cycle
(see issue3681).
Note that commit created during edit are not affected yet.
The old and fragile patching logic is replaced by smart merges (as rebase and
graft do). This should prevents some conflicts and smoother human resolution.
For this purpose the "foldchanges" function is renamed to "applychanges" and
handle a single revision only.
Update the folding code to works in memory instead of applying patches on the
working directory. This is cleaner, faster and prepare the removal of the whole
patching logic.
This new collapse function will probably move into core sooner or later. A lot
of other rewriting operation may benefit from it.
When running the following actions:
pick 617f94f13c0f 1 +4
drop 888f9082bf99 2 +5
fold 251d831eeec5 3 +6
if the fold fails, is fixed by the user with a new changeset, --continue
will ignore the new revision when generating the fold changelog. This
was caused by --continue detecting new changesets as descendants of the
parent not descendants of changesets in the initial list. In this case,
dropped changesets must be ignored.
Even with the computation fixed, the 'newchildren' list was always
emptied by the filtering loop and passed empty to finishfold().
Note that changesets dropped and recreated identically will still be
missed. This probably cannot be solved but is unlikely to happen.
Other things, like 'newchildren' having multiple heads, should be
checked as well.
