Destroying history via strip used to invalidate the branchheads cache,
causing it to be regenerated the next time it is read. This is
expensive in large repos. This change converts strip to pass info to
localrepo.destroyed() to enable to it to incrementally update the
cache, improving the performance of strip and other operations that
depend on it (e.g., rebase).
This change also strengthens a bit the integrity checking of the
branchheads cache when it is read, by rejecting the cache if it has
nodes in it that no longer exist.
Messing with the dirstate before the intermediate commit seems error prone.
Instead, commit and recompute the copies with copies.pathcopies(), then use
that with commitctx().
Since copies.pathcopies() does not support file replacement very well, the
whole .renamed() condition in samefile() is removed and the "file replacement
caused by differing copy source" effect is discarded.
Test shamelessly stolen from Idan Kamara <idankk86@gmail.com>
The weirdness is --amend let you replace one file with another with same data
and flags if the new file copy record differ from the one in the parent
revision. In theory, there is no problem with this kind of thing, subversion
supports it, but here we see log and status disagree. The reason is log reads
the copy record from the filelog, while status calls copies.pathcopies() which
eventually invokes some expensiveness argument to discard this case (copies.py,
_forwardcopies(), line 132). Since the next patch will side with pathcopies(),
I prefer to call this behaviour a bug.
The --amend flag can be used to amend the parent of the working directory
with a new commit that contains the changes in the parent in addition to
those currently reported by "hg status", if there are any. The old commit
is stored in a backup bundle in ".hg/strip-backup"(see "hg help bundle"
and "hg help unbundle" on how to restore it).
Message, user and date are taken from the amended commit unless specified.
When a message isn't specified on the command line, the editor will open
with the message of the amended commit.
It is not possible to amend public changesets (see "hg help phases") or
changesets that have children.
Behind the scenes, first commit the update (if there is one) as a regular
child of the current parent. Then create a new commit on the parent's
parent with the updated contents. Then change the working copy parent
to this new combined changeset. Finally, strip the amended commit and
update commit created in the beginning.
An alternative (cleaner?) approach of doing this is suggested here:
http://selenic.com/pipermail/mercurial-devel/2012-March/038540.html
It is currently not possible to amend merge commits or recursively,
this can be added at a later time.
