Previously, a backup bundle could overwrite an existing bundle and cause user
data loss. For instance, if you have A<-B<-C and strip B, it produces backup
bundle B-backup.hg. If you then hg pull -r B B-backup.hg and strip it again, it
overwrites the existing B-backup.hg and C is lost.
The fix is to add a hash of all the nodes inside that bundle to the filename.
Fixed up existing tests and added a new test in test-strip.t
Before this patch, "memctx._status" is initialized by "(files, [], [],
[], [], [], [])" and this causes "memctx.modified" to include not
only modified files but also added and removed ones incorrectly.
This patch adds "_status" method to calculate exact status being
committed according to "files" specified at construction time.
Exact "_status" is useful to share/reuse logic of committablectx.
This patch is also preparation for issues fixed by subsequent patches.
Some details of changes for tests in this patch:
- some filename lines are omitted in "test-convert-svn-encoding.t",
because they are correctly listed up as "removed" files
those lines are written out in "localrepository.commitctx" for
"modified" and "added" files by "ui.note".
- "| fixbundle" filterring in "test-histedit-fold.t" is omitted to
check lines including "added" correctly
"fixbundle" discards all lines including "added".
History rewriting commands like histedit tend to use temporary
commits. They may schedule hook execution on these temporary commits
for after the lock has been released. But temporary commits are likely
to have been stripped before the lock is released (and the hook run).
Hook executed for missing revisions leads to various crashes.
We disable hooks execution for revision missing in the repo. This
provides a dirty but simple fix to user issues.
When the authorship of the changeset folded in does not match that of
the base changeset, we currently use the configured ui.username
instead. This is especially surprising when the user is not the author
of either of the changesets. In such cases, the resulting authorship
(the user's) is clearly incorrect. Even when the user is folding in a
patch they authored themselves, it's not clear whether they should
take over the authorship. Let's instead keep it simple and always
preserve the base changeset's authorship. This is also how
"git rebase -i" handles folding/squashing.
This new histedit command (short for "rollup") is a variant of "fold" akin to
"hg amend" for working copy: it accumulates changes without interrupting
the user and asking for an updated commit message.
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.
