merge: undocument checkunknown and checkignored configs for 3.7 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.

commands: advance current active bookmark at pull --update correctly 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)

largefiles: prevent committing a missing largefile 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.

changegroup: fix treemanifest exchange code (issue5061) 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.

log: speed up single file log with hidden revs (issue4747) 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.

largefiles: report the missing file count after a commit that does nothing This is the same warning that is printed for normal files.

commit: factor the post commit status check into a cmdutil method 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.

largefiles: fix an explicit largefile commit after a remove (issue4969) The change in b68797f244e4 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]

context: back out sneaky code change in documentation change In 81b391a45264 (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.

templater: abort if infinite recursion detected while compiling In this case, a template is parsed recursively with no thunk for lazy evaluation. This patch prevents recursion by putting a dummy of the same name into a cache that will be referenced while parsing if there's a recursion. changeset = {files % changeset}\n ~~~~~~~~~ = [(_runrecursivesymbol, 'changeset')]