test-commit-amend: add globs for Windows

lazymanifest: use a binary search to do an insertion This makes insertions log(n) plus some memmove() overhead, rather than doing an append followed by an n*log(n) sort. There's probably a lot of performance to be gained by adding a batch-add method, which could be smarter about the memmove()s performed. Includes a couple of extra tests that should help prevent bugs. Thanks to Martin for some significant pre-mail cleanup of this change.

context: don't sort manifest entries The manifest iterator is now pre-sorted, so we can skip this check.

manifest: use custom C implementation of lazymanifest This version is actually lazy, unlike the pure-python version. The latter could stand to be optimized if anyone actually wants to use it seriously. I put no work into it. Before any of my related changes on mozilla-central: perfmanifest tip ! wall 0.268805 comb 0.260000 user 0.260000 sys 0.000000 (best of 37) perftags ! result: 162 ! wall 0.007099 comb 0.000000 user 0.000000 sys 0.000000 (best of 401) perfstatus ! wall 0.415680 comb 0.420000 user 0.260000 sys 0.160000 (best of 24) hgperf export tip ! wall 0.142118 comb 0.140000 user 0.140000 sys 0.000000 (best of 67) after all of my changes on mozilla-central: ./hg: perfmanifest tip ! wall 0.232640 comb 0.230000 user 0.220000 sys 0.010000 (best of 43) perftags ! result: 162 ! wall 0.007057 comb 0.010000 user 0.000000 sys 0.010000 (best of 395) perfstatus ! wall 0.415503 comb 0.420000 user 0.280000 sys 0.140000 (best of 24) hgperf export tip ! wall 0.025096 comb 0.030000 user 0.030000 sys 0.000000 (best of 102) so it's no real change in performance on perf{manifest,tags,status}, but is a huge win on 'hgperf export tip'. There's a little performance work that could still be done here: fastdelta() could be done significantly more intelligently by using the internal state of the lazymanifest type in C, but that seems like good future work.

manifest: split manifestdict into high-level and low-level logic The low-level logic type (_lazymanifest) matches the behavior of the C implementation introduced in a5f1bccd. A future patch will use that when available.

manifest: do parsing inside manifestdict contstructor This shape to the code will make using a C implementation of the manifest storage easier.

manifest: move parsing functions up in file These functions are about to change signature and be hidden inside the manifestdict constructor. Doing the code motion now as an isolated change to make things easier to review.

dispatch: offer suggestions of similar-named commands When suggestions are available, we show those suggestions instead of showing some help output.

dispatch: offer near-edit-distance suggestions for {file,rev}set functions Before this patch, when I have a brain fart and type `hg log -r 'add(foo)'`, hg exits and just says add isn't a function, leading me to the help page for revset to figure out how to spell the function. With this patch, it suggests 'adds' as a function I might have meant.

test-revset: add tests for missing function output An upcoming change will slightly alter behavior here. Adding the test now so the output change stands out in the later changeset.

revset: use UnknownIdentifier where appropriate

fileset: use UnknownIdentifier where appropriate

error: add a new UnknownIdentifier error type This will be used by the revset and fileset code to communicate more specific errors to higher levels so that we might be able to offer suggestions about what function might have been similar.

log: display closing-branch nodes as "_" (BC) In plain `hg log` there is no indication that a commit closes a branch. You can use hg log --debug, but this is too verbose. A simple idea copied from thg and other graphical viewers is to display the node for a closing-branch commit as a horizontal line. I think this technically is a BC if we consider the graphlog to be part of the stdout API, but I really can't imagine who the hell is parsing the graphlog to determine information about commits.

manifest: move pure parsing code out of pure This lets us transition more smoothly.

manifest.c: new extension code to lazily parse manifests This lets us iterate manifests in order, but do a _lot_ less work in the common case when we only care about a few manifest entries. Many thanks to Mike Edgar for reviewing this in advance of it going out to the list, which caught many things I missed. This version of the patch includes C89 fixes from Sean Farley and many correctness/efficiency cleanups from Martin von Zweigbergk. Thanks to both!

workingctx: use normal dirs() instead of dirstate.dirs() The workingctx class was using dirstate.dirs() as it's implementation. The sparse extension maintains a pruned down version of the dirstate, so this resulted in the workingctx reporting an incorrect listing of directories during merge calculations (it was detecting directory renames when it shouldn't have). The fix is to use the default implementation, which uses workingctx._manifest, which unions the manifest with the dirstate to produce the correct overall picture. This also produces more accurate output since it will no longer return directories that have been entirely deleted in the dirstate. Tests will be added to the sparse extension to detect regressions for this.

merge with stable

subrepo: only fetch unknown files from git when explicitly requested

subrepo: always return scmutil.status() from gitsubrepo.status() This was accidentally left out of c95db3208a33.

subrepo: explicitly request clean and unknown files in status for git's add No behavior changes here since gitsubrepo.status() doesn't currently populate clean, and ignores whether unknown files were actually requested. But this is in line with other calls to status, and should avoid future surprises.

largefiles: handle logging from outside the repo It's probably possible to refactor so that the 'if m._cwd' check isn't necessary, but the False case is the typical case (i.e. run from the root of the repo), and simpler to read. An exact path to a largefile from outside the repo was previously ignored. match.rel('.hglf') will handle figuring out both the correct '../' length to the standin directory if inside the repo, or path/to/repo from outside, at the cost of a pconvert() to keep the patterns using '/' on Windows.

largefiles: don't prefix standin patterns with '.hglf' when logging When logging '.hglf/foo', the pattern list was being transformed from ['.hglf/foo'] into ['.hglf/foo', '.hglf/.hglf/foo']. Aside from the pathological case of somebody getting a directory named '.hglf' created inside the standing directory, the old code shouldn't have had any bad effects. (amended by mpm to sort patterns for test stability and not upset check-code)

largefiles: teach log to handle patterns Adding the standin to the patterns list was (possibly) harmless before, but was wrong, because the pattern list was already updated above that code. Now that patterns are handled, it was actually harmful. For example, in this test: $ hg log -G glob:**another* the adjusted pattern list would have been: ['glob:**another*', '.hglf/.', 'glob:.hglf/**another*'] which causes every largefile in the root to be matched. I'm not sure why 'glob:a*' picks up the rename of a -> b commit in test-log.t, but a simple 'a' doesn't. But it doesn't appear to be caused by the largefiles extension.

check-code: allow disabling msys path check

revset: extend fullreposet to make "null" revision magically appears in set As per fullreposet.__and__, it can omit the range check of rev. Therefore, "null" revision is accepted automagically. It seems this can fix many query results involving null symbol. Originally, the simplest "(null)" query did fail if there were hidden revisions. Tests are randomly chosen. fullreposet mimics the behavior of localrepo, where "null" revision is not listed but contained.

revset: duplicate spanset.__contains__ to fullreposet for modification 1d7a2771aa36 says we should avoid function calls in __contains__, so super(fullreposet, self).__contains__(rev) is not an option. Actually the super call doubled the benchmark result of trivial query: revisions: 0) 678f53865c68 (tip when I wrote this patch) 1) rev == node.nullrev or super(fullreposet, self).__contains__(rev) revset #0: tip:0 0) wall 0.008441 comb 0.010000 user 0.010000 sys 0.000000 (best of 282) 1) wall 0.016152 comb 0.010000 user 0.010000 sys 0.000000 (best of 146)

revset: have all() filter out null revision I'm not sure if "all()" should filter out "null", but "all()" is stated as 'the same as "0:tip"' (except that it doesn't reorder the subset, I think.) This patch is intended to avoid exposing a fullreposet to graphmod.dagwalker(), which would result in strange drawing in future version: | o changeset: 0:f8035bb17114 | user: test | date: Thu Jan 01 00:00:00 1970 +0000 | summary: add a caused by: parents = sorted(set([p.rev() for p in ctx.parents() if p.rev() in revs])) We cannot add "and p.rev() != nullrev" here because revs may actually include "null" revision.

revset: drop unnecessary calls of getall() with empty argument If x is None, getall(repo, subset, x) == subset.

graphlog: do not bypass commands.log so that -fr works Since 8b4b9ee6001a, opts dict can be modified in commands.log() before calling cmdutil.graphlog().

histedit: add a config allowing changing histedit rule line length limit Since many users are using terminals wider than 80 chars there should be an option to have longer lines in histedit editor. Even if the summary line is shorter than 80 chars after adding action line prefixes (like "pick 7c2fd3b9020c") it doesn't fit there anymore. Setting it to for example 110 would be a nice option to have.

dirstate: make sure rootdir ends with directory separator (issue4557) ntpath.join() of Python 2.7.9 does not work as expected if root is a UNC path to top of share. This patch doesn't take care of os.altsep, '/' on Windows, because root should be normalized by realpath().

i18n-de: fix a typo in the german translation

histedit: fix style of new error message - lowercase - no punctuation - brief - short node

Makefile: allow setting HGTESTFLAGS in shell environment for TESTFLAGS I keep wanting to run 'make tests', but I forget to set TESTFLAGS='-j 16' or whatever is reasonable for my machine. This lets me just set it once in my shell settings and forget it.

Makefile: introduce testpy-% target for testing with a specifc Python This makes it easy to do 'make testpy-2.4.6 TESTFLAGS="-j 16"' and the Makefile will build Python if needed and then run tests (with -j 16) with the resulting Python. You can set the environment variable HGPYTHONS to a nice location on your machine to cache the Python builds globally. If that's not set, it builds them inside build/pythons.

extdiff: expand tildes and variables in paths to user-supplied diff programs

setup.py: do not install c extensions on pypy These extensions are slower on pypy because pypy has a JIT compiler. And also, they often do not compile (it depends on the pypy configuration).

copyright: update to 2015 Many files and translations have an outdated copyright date. Change that to the correct "2005-2015" dates.

changegroup: emit full-replacement deltas if either revision is censored To ensure that exchanged deltas in the presence of censored revisions can always be applied to the recipient repository, the deltas must replace the entire base text. To make this restriction reasonably enforceable, the delta must do so with a single patch operation. For background and broader design of the censorship feature, see: http://mercurial.selenic.com/wiki/CensorPlan

log: make -fr show complete history from the given revs Right now it's very obtuse to show the history of a particular rev (hg log -r 'reverse(::foo)'). This changes the -f option to make it follow history for the revs specified by -r. The current -f -r behavior is to limit the result of -r to only the commits that are ancestors of the current working copy. Changing this is a bit of a BC break, but the old behavior is A) rare, B) easy to emulate (& ::.), and C) currently undefined. The new behavior is frequently requested enough that I think the change is worth it.

util: accept "now, today, yesterday" for dates even the locale is not english Hi there! Fixed date names are helpful for automated systems. So it is possible to use english date parameter even if the underlying system uses another locale. We have here a jenkins with build jobs on different slaves that will do some operations with "dates" parameter. Some systems uses English locale and some systems uses German locale. So we needed to configure the job to uses other date names. As this is really annoying to keep the systems locale in mind for some operations I looked into util.py. It would be helpful for automated systems if the "default English" date names would even usable on other locales. I attached a simple patch for this. Best regards André Klitzing

copies: only calculate 'addedinm[12]' sets once Pass the addedinm1 and addedinm2 instead of m1, m2, ma into _computenonoverlap() instead of calculating the sets twice.

copies: calculate 'bothnew' from manifestdict.filesnotin() In the same spirit as the previous change, let's now calculate the 'bothnew' variable using manifestdict.filesnotin().5D

copies: replace _nonoverlap() by calls to manifestdict.filesnotin() Now that we have manifestdict.filesnotin(), we can write _nonoverlap() in terms of that method instead, enabling future speedups when filesnotin() gets optimized, and perhaps making the code a little clearer at the same time.

copies: move code into new manifestdict.filesnotin() method copies._computeforwardmissing() finds files in one context that is not in the other. Let's move this code into a new method on manifestdict, so m1.filesnotin(m2) can be optimized for various types of manifests (we expect more types of manifests soon).

subrepo: warn when adding already tracked files in gitsubrepo This follows normal Mercurial rules, and the message is lifted from workingctx.add(). The file is printed with abs() to be consistent with how it is printed in workingctx, even though that is inconsistent with how added files are printed in verbose mode. Further, the 'already tracked' notifications come after all of the files that are added are printed, like in Mercurial. As a side effect, we now have the reject list to return to the caller, so that 'hg add' exits with the proper code. It looks like an abort occurs if git fails to add the file. Prior to touching 'snake.python' in the test, this was the result of attempting to add the file after a 'git rm': fatal: pathspec 'snake.python' did not match any files abort: git add error 128 in s (in subrepo s) I'm not sure what happens when git is a deep subrepo, but the 'in s' and 'in subrepo s' from @annotatesubrepoerror are redundant here. Maybe we should stat the files before invoking git to catch this case and print out the prettier hg message? The other thing missing from workingctx.add() is the call to scmutil.checkportable(), but that would need to borrow the parent's ui object.

subrepo: don't exclude files in .hgignore when adding to git The previous test gave a false success because only an hg-ignored pattern was specified. Therefore match.files() was empty, and it fell back to the files unknown to git. The simplest fix is to always consider what is unknown to git, as well as anything specified explicitly. Files that are ignored by git can only be introduced by an explicit mention in match.files().

dirstate: clarify comment about leaving normal files undef if changed 'now' Clarify that they only are saved as undef if they were marked as normal and changed in the same second.

spelling: fixes from proofreading of spell checker issues

merge-tools: configuration for Beyond Compare on OS X Based on the Linux configuration entry.

convert: when converting from monotone, use the number 1 for close in extras Monotone used '1' for close while core Mercurial use 1. Now, for consistency, use the same value everywhere. It will be stored as a string anyway and the change will not make any real difference. (The actual value of 'close' doesn't matter as long as extras has such a key.)

hgweb: extract changeset template mapping generation to own function Similar in spirit to 513d47905114, I want to write an extension to make available extra template keywords so hgweb templates can include extra data. To do this today requires monkeypatching the templater, which I think is the wrong place to perform this modification. This patch extracts the creation of the templater arguments to a standalone function - one that can be monkeypatched by extensions. I would very much like for extensions to be able to inject extra templater parameters into *any* template. However, I'm not sure the best way to facilitate this, as hgweb commands invoke the templater before returning and we want the extensions to have access to rich data structures like the context instances. We need cooperation inside hgweb command functions. The use case screams for something like internal-only "hooks." This is exactly what my (rejected) "events" patch series provided. Perhaps that feature should be reconsidered...

merge with stable

revrange: don't parse revset aliases as hash prefixes (issue4553) If a user has a revsetalias defined, it is their explicit wish for this alias to be parsed as a revset and nothing else. Although the case of the alias being short enough and only contain the letters a-f is probably kind of rare, it may still happen.

subrepos: support adding files in git subrepos This support includes correct matching, so includes, excludes and patterns are all supported.

subrepo: return only the manifest keys from hgsubrepo.files() This is in line with the other subrepo classes (i.e. only the filenames are returned). Archive iterates over the manifest keys, and since subrepo archive() uses this method, it does too now. This will allow largefiles to override its manifest keys to present the largefiles instead of the standins. Once in place, we shouldn't need the copy/paste overrides of archive and subrepo archive in largefiles, that don't quite behave like the core methods they are overriding.

archive: change the default prefix to '' from None All current callers supply some sort of prefix, so the issue was hidden. But if no parameter was specified, a crash occurred in the write() closure when concatenating 'prefix' and 'name'.

debugsetparent: document one common caveat specifically After calling debugsetparent, it's quite common that status is incorrect. The command's help text already says that it should be used with care, but let's describe this caveat explicitly since it's probably the most common one.

repair: setup hookargs when processing bundle2s addchangegroup() modifies its behavior based on the transaction source. This is incorrect for bundle2 repair files, causing rebases to abort when this option is enabled. This diff specifies the source type in the way recommended by comments in bundle2.py and adds a test to ensure that rebases with the experimental option work successfully.

amend: check for directory renames for both merge parents (issue4516) Before this change, amending a merge would lose the rename information for file adding in the second parents and implicitly renamed into a new directory. In case of the merge, we also look for directory rename data from the second parent. This seems to fix the bug and does not show other issues from the test suite.

merge with stable

largefiles: avoid infinite recursive call of openlfdirstate in overriderevert When there isn't lfdirstate file in cases below, "openlfdirstate()" call "scmutil.match()" indirectly to build lfdirstate up. - subrepos disabling largefiles locally - lfdirstate file is missed accidentally This causes infinite recursive call of "openlfdirstate()" in "overriderevert()" (introduced by 79c2c29c71ae), because "openlfdirstate()" is invoked from the function overriding "scmutil.match()" itself. To avoid infinite recursive call of "openlfdirstate()" in "overriderevert()" in such cases, this patch passes "create=False" argument to "openlfdirstate()". "create=False" forcibly makes "openlfdirstate()" avoid code path to build lfdirstate up.

Added signature for changeset 07a92bbd02e5

Added tag 3.3.2 for changeset 07a92bbd02e5

transaction: really disable hardlink backups (issue4546)

merge with stable

test-obsolete: use 'log -T {node}' instead of 'id --debug -i' to lookup hash I ran into a case when adding a test where there were cryptic hg command line errors. I eventually traced it back to 'hg id' printing debug messages before the hash: invalid branchheads cache (served): tip differs <hash> This method should eliminate any other output except the node.

Added signature for changeset 5b4ed033390b

Added tag 3.3.1 for changeset 5b4ed033390b

revisionbranchcache: fall back to slow path if starting readonly (issue4531) Transitioning to Mercurial versions with revision branch cache could be slow as long as all operations were readonly (revset queries) and the cache would be populated but not written back. Instead, fall back to using the consistently slow path when readonly and the cache doesn't exist yet. That avoids the overhead of populating the cache without writing it back. If not readonly, it will still populate all missing entries initially. That avoids repeated writing of the cache file with small updates, and it also makes sure a fully populated cache available for the readonly operations.

largefiles: access to specific fields only if largefiles enabled (issue4547) Even if largefiles extension is enabled in a repository, "repo" object, which isn't "largefiles.reposetup()"-ed, is passed to overridden functions in the cases below unexpectedly, because extensions are enabled for each repositories strictly. (1) clone without -U: (2) pull with -U: (3) pull with --rebase: combination of "enabled@src", "disabled@dst" and "not-required@src" cause this situation. largefiles requirement @src @dst @src result -------- -------- --------------- -------------------- enabled disabled not-required aborted unexpectedly required requirement error (intentional) -------- -------- --------------- -------------------- enabled enabled * success -------- -------- --------------- -------------------- disabled enabled * success (only for "pull") -------- -------- --------------- -------------------- disabled disabled not-required success required requirement error (intentional) -------- -------- --------------- -------------------- (4) update/revert with a subrepo disabling largefiles In these cases, overridden functions cause accessing to largefiles specific fields of not "largefiles.reposetup()"-ed "repo" object, and execution is aborted. - (1), (2), (4) cause accessing to "_lfstatuswriters" in "getstatuswriter()" invoked via "updatelfiles()" - (3) causes accessing to "_lfcommithooks" in "overriderebase()" For safe accessing to these fields, this patch examines whether passed "repo" object is "largefiles.reposetup()"-ed or not before accessing to them. This patch chooses examining existence of newly introduced "_largefilesenabled" instead of "_lfcommithooks" and "_lfstatuswriters" directly, because the former is better name for the generic "largefiles is enabled in this repo" mark than the latter. In the future, all other overridden functions should avoid largefiles specific processing for efficiency, and "_largefilesenabled" is better also for such purpose. BTW, "lfstatus" can't be used for such purpose, because some code paths set it forcibly regardless of existence of it in specified "repo" object.

templatekw: fix {join(bookmarks, sep)} to always show associated bookmarks The default joinfmt, "x.values()[0]", can't be used here because it picks either 'bookmark' or 'current' randomly. I got wrong result with PYTHONHASHSEED=1 on my amd64 machine.

templatekw: inline showlist() into showbookmarks() showlist() is the helper to build _hybrid object from a trivial list. It can't be applied if each value has more than one items, 'bookmark' and 'current' in this case. This change is necessary to fix random failure of "{join(bookmarks, sep)}".

transaction: disable hardlink backups (issue4546) Causing troubles, simplest fix.

repoview: invalidate cached changelog if _delayed changes (issue4549) Starting with 2d54aa5397cd, when a clone reached the checkout stage, the cached changelog in the filtered view was still seeing the _delayed flag, even though the changelog had already been finalized.

test: make test-extdiff resilient to */gnubin/echo My Mac test machine has 'echo' in '/opt/local/libexec/gnubin/echo' since, well, GNU is not BSD. Also, I feel it need to be said about using regexes: Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

dispatch: work around UnicodeDecodeError caused by SSLError of Python 2.7.9 SSLError of Python 2.7.9 may keep error message in unicode. It will be wrapped by URLError(reason) at KeepAliveHandler.do_open, so inst.reason can be a unicode. https://hg.python.org/cpython/file/v2.7.9/Modules/_ssl.c#l329

revset: mask specific names for named() predicate Before this patch, revset predicate "tag()" and "named('tags')" differ from each other, because the former doesn't include "tip" but the latter does. For equivalence, "named('tags')" shouldn't include the revision corresponded to "tip". But just removing "tip" from the "tags" namespace causes breaking backward compatibility, even though "tip" itself is planned to be eliminated, as mentioned below. http://selenic.com/pipermail/mercurial-devel/2015-February/066157.html To mask specific names ("tip" in this case) for "named()" predicate, this patch introduces "deprecated" into "namespaces", and makes "named()" predicate examine whether each names are masked by the namespace, to which they belong. "named()" will really work correctly after 3.3.1 (see 873eb5db89c8 for detail), and fixing this on STABLE before 3.3.1 can prevent initial users of "named()" from expecting "named('tags')" to include "tip". It is reason why this patch is posted for STABLE, even though problem itself isn't so serious. This may have to be flagged as "(BC)", if applied on DEFAULT.

i18n-pt_BR: synchronized with 756c5c8331b0

i18n-ja: synchronized with 756c5c8331b0

merge with stable

manifest: rename 'mf', 'map', and 'mapping' to 'm' We mostly call manifest variables 'm', so let's use that in manifest.py too. This makes it clearer that the variables do, in fact, contain manifestsdict instances and never a plain dict.

manifest: make copy logic local to copy() The optional arguments to the manfifestdict constructor are only used by copy(), so assign the fields from that method instead so it's clear that the arguments are not used for anything else.

extensions: indicate loaded for an immediately called afterload callback Otherwise, there's no way to tell between the immediate callback when it is already loaded, and when the extension is not loaded at all.

tests: add test showing tags cache drops filtered heads (issue4550) The tags cache can lose .hgtags filenode entries for filtered heads. Add a test demonstrating this (bad) behavior.

tags: write tags cache deterministically An upcoming test verifies content of the .hg/cache/tags file. During testing, inconsistent output was observed. This is the result of iterating over a dictionary. Throw a sorted() around tags entries to ensure .hg/cache/tags is written deterministically so test output is stable.

histedit: add --edit-plan option to histedit --edit-plan allows user to edit remaining histedit rules in the middle of histedit process

histedit: generalize makedesc Allow makedesc to generate description for any action - not only pick. (to be used in histedit --edit-plan)

histedit: extract method ruleeditor Extract functionality of editing histedit rules to separate method so we can reuse it in upcoming --edit-plan option.

churn: deprecate -t option in favour of -T We use -T consistently elsewhere to refer to the --template option. The old -t option is now renamed to --oldtemplate so that -t still works. This has the benign side effect of introducing and immediately deprecating a new long option. We also test with both -t and -T options.

pull: print "pulling from foo" before accessing the other repo 1. This is consistent with pushing. 2. This allows to see the URL of the other repo in case accessing the repo fails, e.g. wrong ssh path or issues with the https certificate, without using --debug or showconfig paths. Additionally add test for this in the context of ssh with a wrong path.

error.LookupError: rename 'message' property to something else At least some installs of Python 2.6+ complain with: mercurial/error.py:26: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6 This patch renames the property away from 'message' so that Python no longer complains.

hgweb: use introrev() for finding parents (issue4506) The issue is titled "filtered revision 'XXX' (not in 'served' subset)" and that is the error message you sometimes get when trying to look at a file (/file or /annotate) in hgweb. For example: http://hg.intevation.org/mercurial/crew/file/90cf454edd70/mercurial/cmdutil.py This happens when a parent revision for a file is hidden, thus it is not 'served' and isn't accessible in hgweb by default. When hgweb tries to access such changeset, it produces the error and HTTP status code 404. Another detail is that the parents() function, that is used in multiple places in hgweb, sometimes returned changesets that were obsoleted by the current changeset for the file. For example, when using rebase with evolve and rebasing a divergent changeset that introduces a file on top of current branch. Or grafting a change and making the new grafted changeset obsolete the source (shown in the test case). The result is the same - the obsoleted changeset was mistakingly returned from parents(), even though it's not a parent and the only link to the new changeset is an obsoletion marker (and rebase/graft metadata? not sure it matters). The problem is fixed by using introrev() instead of linkrev() for finding parents. This prevents parents() function from returning unrelated obsolete changesets. The test case prepares a separate repo because (afaict) all other test cases never reuse file names, so there are no files that were changed in multiple changesets. So no previously available files have obsolete changesets in their history.

subrepo: drop unused pattern initialization in hgsubrepo revert This passed an empty list to filerevert() if '--all' was specified, otherwise the set of modified files. But then filerevert() immediately switched this and reinitialized 'pats' to an empty list if '--all' was *not* specified.

revert: display full subrepo output with --dry-run Since the point of --dry-run is to show what will happen, the output with and without it should agree. And since revert wasn't being called on subrepos with --dry-run before, revert in the subrepo had to be defanged in this case.