We've discovered an issue with this flag during certain kinds of rebases. When:
(1) we're rebasing while currently on the destination commit, and
(2) an untracked or ignored file F is currently in the working copy, and
(3) the same file F is in a source commit, and
(4) F has different contents in the source commit,
then we'll try to merge the file rather than overwrite it.
An earlier patch I sent honored the options for these situations as well.
Unfortunately, rebases go through the same flow as the old, deprecated 'hg
merge --force'. We'd rather not make any changes to 'hg merge --force'
behavior, and there's no way from this point in the code to figure out whether
we're in 'hg rebase' or 'hg merge --force'.
Pierre-Yves David and I came up with the idea to split the 'force' flag up into
'force' for rebases, and 'forcemerge' for merge. Since this is a very
disruptive change and we're in freeze mode, simply undocument the options for
this release so that our hands aren't tied by BC concerns. We'll redocument
them in the next release.
Before this patch, "hg pull --update" doesn't advance current active
bookmark correctly, if pulling itself doesn't advance it, even though
"hg pull" + "hg update" does so.
Existing test for "pull --update works the same as pull && update" in
test-bookmarks.t doesn't examine this case, because pulling itself
advance current active bookmark before actual updating the working
directory in that test case.
To advance current active bookmark at "hg pull --update" correctly,
this patch examines 'movemarkfrom' instead of 'not checkout'.
Even if 'not checkout' at the invocation of postincoming(), 'checkout'
is overwritten by "the revision to update to" value returned by
destutil.destupdate() in such case. Therefore, 'not checkout'
condition means "update destination is revision #0", and isn't
suitable for examining whether active bookmark should be advanced.
Even though examination around "movemarkfrom == repo['.'].node()" may
seem a little redundant just for this issue, this makes it easier to
compare (and unify in the future, maybe) with the same logic to update
bookmark at "hg update" below.
if not ret and movemarkfrom:
if movemarkfrom == repo['.'].node():
pass # no-op update
elif bookmarks.update(repo, [movemarkfrom], repo['.'].node()):
ui.status(_("updating bookmark %s\n") % repo._activebookmark)
else:
# this can happen with a non-linear update
ui.status(_("(leaving bookmark %s)\n") %
repo._activebookmark)
bookmarks.deactivate(repo)
Previously, if the largefile was deleted at the time of a commit, the standin
was silently not updated and its current state (possibly garbage) was recorded.
The test makes it look like this is somewhat of an edge case, but the same thing
happens when an `hg revert` followed by `rm` changes the standin.
Aside from the second invocation of this in lfutil.updatestandinsbymatch()
(which is what triggers this test case), the three other uses are guarded by
dirstate checks for added or modified, or an existence check in the filesystem.
So aborting in lfutil.updatestandins() should be safe, and will avoid silent
skips in the future if this is used elsewhere.
There were two mistakes: one was accidental reuse of the fclnode
variable from the loop gathering file nodes, and the other (masked by
that bug) was not correctly handling deleted directories. Both cases
are now fixed and the test passes.
On repos with lots of heads, the filelog() code could spend several
minutes decompressing manifests. This change instead tries to
efficiently scan the changelog for candidates and decompress as few
manifests as possible. This is a regression introduced in 3.3 by the
linkrev adjustment code. Prior to that, filelog was nearly instant.
For the repo in the bug report, this improves time of a simple log
command from ~3 minutes to ~.5 seconds, a 360x speedup.
For the main Mercurial repo, a log of commands.py slows down from
1.14s to 1.45s, a 27% slowdown. This is still faster than the file()
revset, which takes 2.1 seconds.
The largefiles extension needs to set lfstatus for this status call. Otherwise,
if a missing largefile is explicitly named, a confusing message is issued that
says the largefile wasn't found, followed by another that says nothing changed.
The change in 6fce9a02f069 to handle a normal -> largefile switch was too
aggressive in preserving the original matcher names. If a largefile is
explicitly provided by the user, but only the standin exists in dirstate, then
only the standin can be committed.
There's still maybe an issue when the largefile is deleted outside of Mercurial:
$ rm large
$ hg ci -m "oops" large
large: The system cannot find the file specified
nothing changed
[1]
In a4119550f1e1 (context: clarify why we don't compare file contents
when nodeid differs, 2016-01-12), I also changed "node2 != _newnode"
into "self.rev() is not None". I don't remember why. They are similar,
but the former also catches the case where the file is clean in the
dirstate (so node2 is not _newnode), but different from the "other"
context. This resulted in unnecessary file content comparison a few
lines further down in the code. Let's just back out the code change.
Thanks to Durham Goode for spotting this.
Now that @command doesn't write back into commands when it is being
executed during the loading of commands.py itself, we are unblocked
from converting cmdutil to absolute_import.
Previously, after matching a single line, any contiguous subsequent lines ending
with (?) would be added to the output and removed from the expected output.
This is a problem if the subsequent test output would have matched the consumed
(?) line, because it kept the optional line and then added a duplicate without
the (?) [1]. Instead, wait until there is nothing more to match before handling
the leftovers.
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-February/080197.html
This can eliminate import cycles and ugly push/pop of global variables at
_checkshellalias(). Attributes of aliascmd are directly accessible.
Because norepo/optionalrepo/inferrepo lists aren't populated, extensions
examining them no longer work. That's why this patch removes these lists
to signal the API incompatibility.
This breaks 3rd-party extensions that are yet to be ported to @command
decorator.
Future patches will make @command decorator set properties such as "norepo" to
a function object. This patch makes sure these properties never be lost by
wrapcommand() or wrapfunction().
This change won't be crazy as the standard functools.wraps() copies __dict__.
Currently, changelog reading decodes read values. This is wasteful
because a lot of times consumers aren't interested in some of these
values.
This patch changes description decoding to occur in changectx as
needed.
revsets reading changelog entries appear to speed up slightly:
revset #7: author(lmoscovicz)
plain
0) 0.906329
1) 0.872653
revset #8: author(mpm)
plain
0) 0.903478
1) 0.878037
revset #9: author(lmoscovicz) or author(mpm)
plain
0) 1.817855
1) 1.778680
revset #10: author(mpm) or author(lmoscovicz)
plain
0) 1.837052
1) 1.764568
mpm isn't a fan of the existing or previous partitioning scheme. He
provided a fantastic justification for why on the mailing list.
This patch adds his words to the code so they aren't forgotten.
At one point run-tests.py and test-run-tests.t worked and passed
under Python 3.5. Various changes to run-tests.py over the past
several months appear to have broken Python 3.5 compatibility.
This patch implements various fixes (all related to str/bytes type
coercion) to make run-tests.py and test-run-tests.t mostly work
again. There are still a few failures in test-run-tests.t due to
issues importing mercurial.* modules. But at least run-tests.py
seems to work under 3.5 again.
We have a dedicated function to get just the list of files in
a changelog entry. Use it.
This will presumably speed up changegroup application since we're
no longer decoding the entire changelog entry. But I didn't measure
the impact.
Changeset 9a4b77db854b introduced a guard against case where obsolete changesets
are included in the rebase in a way this will result in divergence (because
rebase create new successors for changeset which already have successors). In
the same go a 'rebase.allowdivergence' option was introduced to control that
behavior.
We rename this config option to 'experimental.allowdivergence' for multiple
reasons:
* First this behavior is attached to changeset evolution, a feature still
experimental.
* Second, there was no 'rebase' section in config before we introduced this
option. I would like to avoid proliferation of micro config section and
therefore would like to avoid the creation of this new section just for an
experimental feature.
* Third, this guard (warning the user about a history rewriting operation that
will create divergence) will very likely be generalised to all history
rewriting operations, making this not rebase specific.
* Finally, because this will likely be a general guard present a bit everywhere
in the UI we'll likely end up with something better than a config option to
control this behavior, so having the current config option living in
experimental will allow us make it disappear in the future.
So we banish this config option back to the experimental section where it
belongs, killing the newly born 'rebase' config section in the process.
Doing this required the introduction of a mechanism for keeping
track of more general config in the test. At present this is only
used for extensions but it could be used more widely (e.g. to
control specific extension behaviour)
This greatly simplifies the extension management logic by introducing
a general notion of config, which we maintain ourselves and pass to
HG on every invocation.
This results in significantly less error prone test generation, and
also allows us to turn extensions off as well as on.
The logic that used an environment variable to rerun the tests with
an extension disabled now just edits the test file (in a fresh copy)
to remove these --config command line flags.
confighash and mtimehash are often used together. This patch adds a simple
structure called hashstate to store them. hashstate also has a handly method
called fromui to calculate the hashes from a ui object.
