identify: change p1/p2 to a list of parents It makes sense because the nested data structure is a list of items.

scmutil: add a cleanupnodes method for developers It's now common that an old node gets replaced by zero or more new nodes, that could happen with amend, rebase, histedit, etc. And it's a common requirement to do bookmark movements, strip or obsolete nodes and even moving working copy parent. Previously, amend, rebase, history have their own logic doing the above. This patch is an attempt to unify them and future code. This enables new developers to be able to do "replace X with Y" thing correctly, without any knowledge about bookmarks, strip or obsstore. The next step will be migrating rebase to the new API, so it works inside a transaction, and its code could be simplified.

strip: add a delayedstrip method that works in a transaction For long, the fact that strip does not work inside a transaction and some code has to work with both obsstore and fallback to strip lead to duplicated code like: with repo.transaction(): .... if obsstore: obsstore.createmarkers(...) if not obsstore: repair.strip(...) Things get more complex when you want to call something which may call strip under the hood. Like you cannot simply write: with repo.transaction(): .... rebasemod.rebase(...) # may call "strip", so this doesn't work But you do want rebase to run inside a same transaction if possible, so the code may look like: with repo.transaction(): .... if obsstore: rebasemod.rebase(...) obsstore.createmarkers(...) if not obsstore: rebasemod.rebase(...) repair.strip(...) That's ugly and error-prone. Ideally it's possible to just write: with repo.transaction(): rebasemod.rebase(...) saferemovenodes(...) This patch is the first step towards that. It adds a "delayedstrip" method to repair.py which maintains a postclose callback in the transaction object.

workingfilectx: add audit() as a wrapper for wvfs.audit()

workingfilectx: add backgroundclose as a kwarg to write() This is necessary because some callers in merge.py pass backgroundclose=True when writing. As with previous changes in this series, this should be a no-op.

merge: change repo.wvfs.setflags calls to a new wctx[f].setflags function As with previous changes in this series, this should be a no-op.

merge: convert repo.wwrite() calls to wctx[f].write() As with the previous patch in this series, workingfilectx.write() is a direct call to repo.wwrite(), so this change should be a no-op.

merge: replace repo.wvfs.unlinkpath() with calls to wctx[f].remove() The code inside workingfilectx.remove() is a straight call to repo.wvfs.unlinkpath, so this should be a no-op.

merge: pass wctx to batchremove and batchget We would like to migrate direct calls of repo.wvfs/wwrite/wread/etc to a call on the relevant workingfilectx, both as a cleanup (to reduce the number of working copy functions on `repo`), and also to facilitate an in-memory merge that doesn't write to the working copy. In order to do that, the first step is to ensure we pass the target wctx around and perform our writes and reads on it. Later, this object might become a memctx.

revset: add depth limit to descendants() (issue5374) This is naive implementation using two-pass scanning. Tracking descendants isn't an easy problem if both start and stop depths are specified. It's impractical to remember all possible depths of each node while scanning from roots to descendants because the number of depths explodes. Instead, we could cache (min, max) depths as a good approximation and track ancestors back when needed, but that's likely to have off-by-one bug. Since this implementation appears not significantly slower, and is quite straightforward, I think it's good enough for practical use cases. The time and space complexity is O(n) ish. revisions: 0) 1-pass scanning with (min, max)-depth cache (worst-case quadratic) 1) 2-pass scanning (this version) repository: mozilla-central # descendants(0) (for reference) *) 0.430353 # descendants(0, depth=1000) 0) 0.264889 1) 0.398289 # descendants(limit(tip:0, 1, offset=10000), depth=1000) 0) 0.025478 1) 0.029099 # descendants(0, depth=2000, startdepth=1000) 0) painfully slow (due to quadratic backtracking of ancestors) 1) 1.531138

dagop: make walk direction switchable so it can track descendants # ancestors(tip) using hg repo 2) 0.068527 3) 0.069097

dagop: factor out generator of ancestor nodes # ancestors(tip) using hg repo 1) 0.068976 2) 0.068527

dagop: factor out pfunc from revancestors() generator This generator will be reused for tracking descendants with depth limit. # ancestors(tip) using hg repo 0) 0.065868 1) 0.068976

dagop: use smartset.min() in revdescendants() generator All callers pass the result of revset.getset(), which should be a smartset.

dagop: change revdescendants() to include all root revisions Prepares for adding depth support. I want to process depth=0 in revdescendants() to make things simpler. only() also calls dagop.revdescendants(), but it filters out root revisions explicitly. So this should cause no problem. # descendants(0) using hg repo 0) 0.052380 1) 0.051226 # only(tip) using hg repo 0) 0.001433 1) 0.001425

test-revset: add a few more tests of descendants() I'll add depth support to descendants().

dagop: unnest inner generator of revdescendants() This just moves iterate() to module-level function.

smartset: fix default value of abstractsmartset.sort() It's unused, but it shouldn't lie.

keyword: wrap functions only once at loading keyword extension Before this patch, some functions are wrapped in reposetup(), but this causes redundant nested wrapping, if two ore more repositories enable keyword extension (e.g. hgweb serves multiple repositories). Now, there is no need to define these wrapper functions in reposetup(), because previous patches made them not directly refer to kwtemplater instanciated in reposetup(). This patch factors these wrapper functions out from reposetup(), and uses them to wrap functions only at once at loading keyword extension.

keyword: use _keywordkwt of repository instead of kwtools['templater'] Now, kwtemplater instance can be obtained via _keywordkwt property of repository.

keyword: obtain kwtemplater instance via repository at runtime Wrapper functions of keyword extension are defined in reposetup(), because they refer to kwtemplater instantiated in reposetup(). This patch makes them obtain kwtemplater instance via repository at runtime. For reviewability, this patch focuses on wrapper functions, which handle generator. This is a part of preparations for defining them statically.

keyword: obtain kwtemplater instance via repository at runtime Wrapper functions of keyword extension are defined in reposetup(), because they refer to kwtemplater instantiated in reposetup(). This patch makes them obtain kwtemplater instance via repository at runtime. This is a part of preparations for defining them statically.

keyword: make wrapped repository and kwtemplater refer to each other Wrapper functions of keyword extension are defined in reposetup(), because they refer to kwtemplater instantiated in reposetup(). But these functions can be defined statically, if kwtemplater can be obtained via repository at runtime. This is a part of preparations for defining them statically. To avoid cyclic reference, this patch makes kwtemplater use weakref to refer related repository instance.

keyword: add test for keyword expansion at serving multiple repositories This is safety for subsequent (and future) patches, which change function wrapping.

keyword: make comparison webcommand suppress keyword expansion Before this patch, diff in "comparison" webcommand doesn't suppress keyword expansion as same as diff output of other webcommands.

keyword: restore kwtemplater.match at the end of wrapped webcommands Before this patch, kwweb_skip doesn't restore kwtemplater.match after wrapped webcommands. This suppresses keyword expansion at wrapped webcommands. Typical usecase of this issue is "file" webcommand after annotate, changeset, filediff or so on. To ensure kwtemplater.match=util.never while original webcommand running, this patch makes kwweb_skip yield values returned by it, because it returns generator object.

keyword: restore kwtemplater.restrict at the end of wrapped patch.diff Before this patch, kwdiff doesn't restore kwtemplater.restrict after invocation of wrapped patch.diff(). This suppresses keyword expansion at subsequent filelog.read(). Typical usecase of this issue is "hg cat" after "hg diff" with command server. In this case, kwtemplater.restrict=True is kept in command server process even after "hg diff". To ensure kwtemplater.restrict=True while original patch.diff() running, this patch makes kwdiff() yield values returned by it, because it returns generator object. Strictly speaking, if filelog.read() is invoked before completely evaluating the result of previous patch.diff(), keyword expansion is still suppressed, because kwtemplater.restrict isn't restored yet. But this fixing should be reasonable enough, because patch.diff() is consumed immediately, AFAIK.

debugrevlog: align chain length, reach, and compression ratio I think this is what the max(...) exists for.

configitems: register 'ui.interactive' That item default value is a bit special (None) so this adds a second proof that everything is still working fine.

config: use '_config' within 'configbytes' This will prevent bugs from using None as the sentinel value (eg: 'ui.interactive')

config: use '_config' within 'configbool' This will prevent bugs from using None as the sentinel value (eg: 'ui.interactive')

config: extract the core config logic into a private method This will make it easier for the other 'configxxx' function to detect unset value.

debugrevlog: also display the largest delta chain span Mercurial read all data between the base of the chain and the last delta when restoring content (including unrelated delta). To monitor this, we add data about the size of the "delta chain span" to debugrevlog.

rebase: clean up rebasestate from active transaction Previously, rebase assumes the following pattern: rebase: with transaction as tr: # top-level ... tr.__close__ writes rebasestate unlink('rebasestate') However it's possible that "rebase" was called inside a transaction: with transaction as tr1: rebase: with transaction as tr2: # not top-level ... tr2.__close__ does not write rebasestate unlink('rebasestate') tr1.__close__ writes rebasestate That leaves a rebasestate on disk incorrectly. This patch adds "removefilegenerator" to notify transaction code that the state file is no longer needed therefore fixes the issue.

test-rebase: add a test showing rebasestate left behind The test demonstrates that .hg/rebasestate is left behind if "rebase" was called inside an existing transaction.

identify: rename 'changed' keyword -> 'dirty' I meant to do this before sending the initial templater support, but forgot. I'm quite surprised that 'dirty' doesn't occur in more user facing contexts, but there are a few, like the help for blackbox. It also more obviously mirrors the '(clean)' state printed by the summary command. I also didn't like that it was just one letter off from {changes} in the {latesttags} sub-keywords, which has a totally different meaning.

dispatch: remove unused _loaded Now, there is no user for dispatch._loaded.

extensions: register functions always at loading extension (issue5601) Before this patch, functions defined in extensions are registered via extra loaders only in _dispatch(). Therefore, loading extensions in other code paths like below omits registration of functions. - WSGI service - operation across repositories (e.g. subrepo) - test-duplicateoptions.py, using extensions.loadall() directly To register functions always at loading new extension, this patch moves implementation for extra loading from dispatch._dispatch() to extensions.loadall(). AFAIK, only commands module causes cyclic dependency between extensions module, but this patch imports all related modules just before extra loading in loadall(), in order to centralize them. This patch makes extensions.py depend on many other modules, even though extensions.py itself doesn't. It should be avoided if possible, but I don't have any better idea. Some other places like below aren't reasonable for extra loading, IMHO. - specific function in newly added module: existing callers of extensions.loadall() should invoke it, too - hg.repository() or so: no-repo commands aren't covered by this. BTW, this patch removes _loaded.add(name) on relocation, because dispatch._loaded is used only for extraloaders (for similar reason, "exts" variable is removed, too).

identify: add template support This is based on a patch proposed last year by Mathias De Maré[1], with a few changes. - Tags and bookmarks are now formatted lists, for more flexible queries. - The templater is populated whether or not [-nibtB] is specified. (Plain output is unchanged.) This seems more consistent with other templated commands. - The 'id' property is a string, instead of a list. - The parents of 'wdir()' have their own list of attributes. I left 'id' as a string because it seems very useful for generating version info. It's also a bit strange because the value and meaning changes depending on whether or not --debug is passed (short vs full hash), whether the revision is a merge or not (one hash or two, separated by a '+'), the working directory or not (node vs p1node), and local or not (remote defaults to tip, and never has '+'). The equivalent string built with {rev} seems much less useful, and I couldn't think of a reasonable name, so I left it out. The discussion seemed to be pointing towards having a list of nodes, with more than one entry for a merge. It seems simpler to give the nodes a name, and use {node} for the actual commit probed, especially now that there is a virtual node for 'wdir()'. Yuya mentioned using fm.nested() in that thread, so I did for the parent nodes. I'm not sure if the plan is to fill in all of the context attributes in these items, or if these nested items should simply be made {p1node} and {p1rev}. I used ':' as the tag separator for consistency with {tags} in the log templater. Likewise, bookmarks are separated by a space for consistency with the corresponding log template. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-August/087039.html

show: show all namespaces in "work" view This commit addresses a number of deficiencies in `hg show work`'s output: * Failure to render tags (it just wasn't implemented) * Failure to render names associated with non-built-in namespaces (e.g. remotenames) * Color names were hardcoded instead of coming from the canonical source in the namespace This change has the intended effect of rendering tags and extra namespaces. It solves an immediate need at Mozilla of having names from a custom namespace printed, which is blocking us from switching from a custom `hg wip` revset/template combo to `hg show work`. Note that the order of branches and bookmarks changes. This is because bookmarks are registered before branches in namespaces.py. We may want to register them last, after tags and branches. Or we may want to added a weighted field to the namespace to control display order. Something to think about. I'm not a big fan of the complexity in the templating layer. There is a lot of code to basically filter out the special case of branch=='default' and tag=='tip'. Ideally, we would iterate over a data structure that had irrelevant/unwanted names pre-filtered. However, I wasn't sure how to best implement this. We probably want {namespaces} to emit everything (its current behavior). I was toying with the following: * {namespacesnondefaults} variation that filtered values * A filter function that operated on {namespaces} (I wasn't sure how to implement this since the filtering layer would see a "hybrid" instance as opposed to something that was definitely an iterable of namespaces.) * A namespaces(...) function where you could specify which values to return. I like this the most. But it really wants named arguments to control filtering and we only support named arguments on revsets, not templates. I figure perfect is the enemy of good and we can refine templating support for namespaces in the future. At least now we have a concrete example of a use case.

tests: add more tests for names rendering in `hg show work` This demonstrates some missing features. This will also help verify that a subsequent change has the intended effect.

namespaces: record and expose whether namespace is built-in Currently, the templating layer tends to treat each namespace as a one-off, with explicit usage of {bookmarks}, {tags}, {branch}, etc instead of using {namespaces}. It would be really useful if we could iterate over namespaces and operate on them generically. However, some consumers may wish to differentiate namespaces by whether they are built-in to core Mercurial or provided by extensions. Expected use cases include ignoring non-built-in namespaces or emitting a generic label for non-built-in namespaces. This commit introduces an attribute on namespace instances that says whether the namespace is "built-in" and then exposes this to the templating layer. As part of this, we implement a reusable extension for defining custom names on each changeset for testing. A second consumer will be introduced in a subsequent commit.

templatekw: expose color name in {namespaces} entries Templates make use of a "log.<namespace>" label. The <namespace> value here differs from the actual namespace name in that the namespace itself is plural but the label/color value is singular. Expose the color name to the templating layer so log.* labels can be emitted for {namespaces}. As part of this, we refactored the logic to eliminate a gnarly comprehension. We store color names in their own dict because the lookup can occur in tight loops and we shouldn't have to go to repo.names[ns] multiple times for every changeset.

show: construct changeset templater during dispatch Previously, we constructed a formatter from a specific template topic. Then from show() we reached into the internals of the formatter to resolve a template string to be used to construct a changeset templater. A downside to this approach was it limited us to having the entire template defined in a single entry in the map file. You couldn't reference other entries in the map file and this would lead to long templates and redundancy in the map file. This commit teaches @showview how to instantiate a changeset templater so we can construct a templater with full access to the map file. To prove it works, we've split "showwork" into components.

cmdutil: use named arguments for changeset_templater.__init__ This will make the API more extensible and easier to use.

bundle: inline applybundle1() We have now gotten rid of all but one caller, so let's inline it there.

bundle: make applybundle() delegate v1 bundles to applybundle1()

bundle: transpose transaction scope with bundle type switch This moves the transaction with-statements outside of the per-bundle-version switches, so the next patch will be a little simpler.

unbundle: move BundleUnknownFeatureError exception handling out This just moves the BundleUnknownFeatureError exception handling one level up so we collect the bundle2.applybundle{,1}() calls together. applybundle1() will never throw the exception, so it should have no functional consequence.

bundle: make applybundle1() return a bundleoperation See previous commit for motivation. It already lets us share a little bit more code in commands.py.

bundle: add a applybundle1() method This is one step towards removing a bunch of "if isinstance(gen, unbundle20)" by treating bundle1 and bundle2 more similarly. The name may sounds ironic for a method in the bundle2 module, but I didn't think it was worth it yet to create a new 'bundle' module that depends on the 'bundle2' module. Besides, we'll inline the method again later.

bundle: extract _processchangegroup() method The new method applies the changegroup and fills in op.records, sharing a little bit of code between the two callers. We'll add another caller soon.

bundle: make combinechangegroupresults() take a bundleoperation Both callers have a bundleoperation. Passing it in lets us share a bit more code.

bundle: move combineresults() from changegroup to bundle2 The results only need to be combined if they come from a bundle2. More importantly, we'll change its argument to a bundleoperation soon, and then it definitely will no longer belong in changegroup.py.

bundle: remove 'op' argument from applybundle() No callers pass in an operation.

test-rebase-conflicts: add a test case about turning obsstore on and off Turning obsstore and allowunstable on, rebase will skip the "can't remove original changesets with unrebased descendants" check. Then rebase could be interrupted (merge conflict), and the user has a chance to turn off obsstore. If rebase continues, the current code may strip irrelevant commits (in the test case added, "C" got stripped unexpectedly). The test case reproduces issue5606. It will be fixed by the "multidest" rebase refactoring being reviewed. The test case itself is relatively separate from the rebase refactoring, therefore sent separately hoping to reduce the number of patches of the main rebase series.

merge with stable

strip: include phases in bundle (BC) Before this patch, unbundling a stripped changeset would make it a draft (unless the parent was secret). This meant that one would lose phase information when stripping and unbundling secret changesets. The same thing was true for public changesets. While stripping public changesets is generally rare, it's done frequently by e.g. the narrowhg extension. We also include the phases in the temporary bundle, just in case stripping were to fail after that point, so the user can still restore the repo including phase information. Before this patch, the phases were left untouched during the bundling and unbundling of the temporary bundle. Only at the end of the transaction would phasecache.filterunknown() be called to remove phase roots that were no longer valid. We now need to call that also after the first stripping, i.e. before applying the temporary bundle. Otherwise unbundling the temporary bundle will cause a read of the phase cache which has stripped changesets in the cache and that fails. Like with obsmarkers, we unconditionally include the phases in the bundle when stripping (when using bundle2, such as when generaldelta is enabled). The reason for doing that for strip but not for bundle is that strip bundles are not meant to be shared outside the repo, so we don't care as much about compatibility.

bundle: add config option to include phases This adds an experimental.bundle-phases config option to include phase information in bundles. As with the recently added support for bundling obsmarkers, the support for bundling phases is hidden behind the config option until we decide to make a bundlespec v3 that includes phases (and obsmarkers and ...). We could perhaps use the listkeys format for this, but that's considered obsolete according to Pierre-Yves. Instead, we introduce a new "phase-heads" bundle part. The new part contains the phase heads among the set of bundled revisions. It does not include those in secret phase; any head in the bundle that is not mentioned in the phase-heads part is assumed to be secret. As a special case, an empty phase-heads part thus means that any changesets should be added in secret phase. (If we ever add a fourth phase, we'll include secret in the part and we'll add a version number.) For now, phases are only included by "hg bundle", and not by e.g. strip and rebase.

bundle2: record changegroup data in 'op.records' (API) When adding support for bundling and unbundling phases, it will be useful to have the list of added changesets. To do that, we return the list from changegroup.apply().

debugcommands: pass part, not read data, into _debugobsmarker() This matches how it's done for _debugchangegroup() and how we will soon do it for _debugphaseheads().

debugcommands: remove unused "all" argument from _debugobsmarkers

dagop: raise ProgrammingError if stopdepth < 0 revset.py should never send such a value.

make: add Debian 9 (Stretch) docker target

make: templatize Debian build target a la e63dfbbdbd07

make: add Ubuntu Zesty docker targets (.deb and ppa) Zesty Zapus was released on 2017-04-13 and will be supported until 2018-01.

docker: install less as a build-time dependency in deb-based distros It's needed since 387a76cac28e, otherwise dpkg-checkbuilddeps errors out.

py3: add utility to forward __str__() to __bytes__() It calls unifromlocal() instead of sysstr() because __bytes__() may contain locale-dependent values such as paths.

share: use dict literal instead of dict(key=value) check-code.py has the rule, but it isn't smart enough to catch this.

py3: use r'' to prevent conversion to bytes by transformer

py3: define __bytes__ for basefilectx class The implementation is shamely copied from the __str__ function

py3: check for bytes instead of str in isinstance

py3: convert kwargs' keys' to str using pycompat.strkwargs() On Python 3, we must have keys of keyword arguments as str.

py3: convert kwargs keys' back to bytes using pycompat.byteskwargs()

py3: use "%d" % val for int rather than pycompat.bytestr Earlier I used pycompat.bytestr() to convert integers to bytes, but we can do b"%d" % val to convert that int to bytes. b'' is already added by the transformer. Thanks to Yuya for suggesting this.

extensions: call afterloaded() with loaded=False for disabled extensions If an extension was loaded but disabled due to a minimumhgversion check it will be present in the _extensions map, but set to None. The rest of the extensions code treats the extension as if it were not present in this case, but the afterloaded() function called the callback with loaded=True.

fetch: remove shorthand of --edit colliding against -e/-ssh in remoteopts (BC) Before this patch, -e/--edit and -e/--ssh of fetch command collide against each other. This causes that -e is treated as shorthand of --edit but doesn't work as same as --edit. Therefore, -e works as neither --edit nor --ssh, in practice. This issue was introduced at 595a69a01129 (or 1.0), which renamed -f/--force-editor to -e/--edit. At that point, -e was already used as shorthand of --ssh. After this patch, -e is treated as shorthand of --ssh. This patch is marked as "(BC)", because -e as shorthand of --edit in existing scripts causes failure (or unexpected result) after this patch. This impact should be less enough, because --edit mainly focuses on interactive use. BTW, test-duplicateoptions.py (since 7d171c05a631 or 1.9) can't detect this kind of issues as expected, because direct invocation of extensions.loadall() doesn't involve registration of commands defined in extensions (this issue is fixed in subsequent patch).

releasenotes: improve parsing around bullet points Earlier, on parsing the bullet points from existing release notes the bullet points after the first one weren't written correctly to the notes file. This patch makes changes to parsereleasenotesfromfile() function that introduces a new bullet_points data structure that tracks the bullets and associated subparagraph. It also makes necessary changes to the tests related to merging of bullets.

bookmarks: factor method _printer out of for loop in printbookmarks This allows even further customization via extensions for printing bookmarks. For example, in hg-git this would allow printing remote refs by just modifying the 'bmarks' parameter instead of reimplementing the old commands.bookmarks method. Furthermore, there is another benefit: now multiple extensions can chain their custom data to bookmark printing. Previously, an extension could have conflicting bookmark output due to which loaded first and overrode commands.bookmarks. Now they can all play nicely together.

bookmarks: factor out bookmark printing from commands

commands: move activebookmarklabel to bookmarks module This is going to be used in an upcoming patch that moves more methods to bookmarks.py.

commands: replace locking code with a context manager Note that this means that we're unnecessarily creating a transaction in the pure "--inactive" (i.e. when deactivating the current bookmark), but that should be harmless.

bookmarks: factor out adding a list of bookmarks logic from commands We keep the lock in the caller so that future devs are aware of the locking implications.

bookmarks: factor out rename logic from commands We keep the lock in the caller so that future devs are aware of the locking implications.

bookmarks: factor out delete logic from commands We keep the lock in the caller so that future devs are aware of the locking implications.

merge with stable

revset: add startdepth limit to ancestors() as internal option This is necessary to implement the set{gen} (set subscript) operator. For example, set{-n} will be translated to ancestors(set, depth=n, startdepth=n). https://www.mercurial-scm.org/wiki/RevsetOperatorPlan#ideas_from_mpm The UI is undecided and I doubt if the startdepth option would be actually useful, so the option is hidden for now. 'depth' could be extended to take min:max range, in which case, integer depth should select a single generation. ancestors(set, depth=:y) # scan up to y-th generation ancestors(set, depth=x:) # skip until (x-1)-th generation ancestors(set, depth=x) # select only x-th generation Any ideas are welcomed. # reverse(ancestors(tip)) using hg repo 3) 0.075951 4) 0.076175

revset: add depth limit to ancestors() This is proposed by the issue5374, and will be a building block of set{gen} (set subscript) operator. https://www.mercurial-scm.org/wiki/RevsetOperatorPlan#ideas_from_mpm # reverse(ancestors(tip)) using hg repo 2) 0.075408 3) 0.075951

dagop: compute depth in revancestors() generator Surprisingly, this makes revset benchmark slightly faster. I don't know why, but it appears that wrapping -inputrev by tuple is the key. So I decided to just enable depth computation by default. # reverse(ancestors(tip)) using hg repo 1) 0.081051 2) 0.075408

dagop: just compare with the last value to deduplicate input of revancestors() Since we're using a max heap, the current rev should be a duplicate only if it equals to the previous one. We don't have to maintain the whole seen set. # reverse(ancestors(tip)) using hg repo 0) 0.086420 1) 0.081051

dagop: bulk rename variables in revancestors() generator - h -> pendingheap: "h" seems too short for variable of long lifetime - current -> currev: future patches will add current "depth" variable - parent -> prev or pctx: short lifetime, follows common naming rules

dagop: comment why revancestors() doesn't heapify input revs at once I wondered why we're doing this complicated stuff without noticing the input revs may be iterated lazily in descending order. c1f666e27345 showed why.

dagop: unnest inner generator of revancestors() This just moves iterate() to module-level function.

hgweb: plug followlines action in annotate view Add the followlines.js script and corresponding parameters as data attribute on <tbody class="sourcelines"> element. Extend CSS rules so that they also match the DOM structure of annotate view. As previously, only address paper and gitweb styles (other styles do not have followlines at all).

hgweb: parameterize the tag name of elements holding followlines selection While plugging followlines.js into "annotate" view, we'll need to walk a different DOM structure from that of "filerevision" view. In particular, the selectable source line element is a <tr> in annotate view (in contrast with a <span> in filerevision view). So make this tag name a parameter of followlines.js script by passing its value as a "selectabletag" data attribute of <pre class="sourcelines"> element. As <pre class="sourcelines"> tags are getting quite long in templates, rewrite them on several lines.

gitweb: wrap table rows of annotate view into a <tbody> element We will use this element to hook data attribute for the followlines.js script to be plugged in annotate view. Also this gets symmetrical with paper style which already has a <tbody> element.