FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 31 Dec 2014 17:55:43 +0900] rev 23710
context: add workingcommitctx for exact context to be committed
Before this patch, "workingctx" is also used for the context to be
committed. But "workingctx" works incorrectly in some cases.
For example, even when only some of changed files in the working
directory are committed, "status()" on "workingctx" object for
committing recognizes files not to be committed as changed, too.
As the preparation for fixing these issues, this patch chooses adding
new class "workingcommitctx" for exact context to be committed,
because switching by the flag (like "self._fixedstatus" or so) in some
code paths of "workingctx" is less readable and maintenancable.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 31 Dec 2014 17:55:43 +0900] rev 23709
context: make unknown/ignored/clean of cached status empty for equivalence
Before this patch, "workingctx.status" caches the result of
"dirstate.status" directly into "self._status".
But "dirstate.status" is invoked with False "list*" arguments in
normal "self._status" accessing route, and this makes
"unknown"/"ignored"/"clean" of status empty.
This may cause unexpected result of code paths internally accessing to
them (accessors for external usage are already removed by previous patch).
This patch makes "unknown"/"ignored"/"clean" of cached status empty
for equivalence. Making them empty is executed only when at least one
of "unknown", "ignored" or "clean" has files, for efficiency.
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 31 Dec 2014 13:48:55 -0800] rev 23708
templatefilters.json: stabilize output
The json filter was previously iterating over keys in an object in an
undefined order. Let's throw a sorted() in there so output is
consistent.
It's somewhat frightening that there are no tests for the json filter.
Subsequent commits will add them, so we pass on the opportunity to add
them here.
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 31 Dec 2014 11:22:17 -0800] rev 23707
templatefilters.json: call functions
The "changeset" template from hgweb is using a lambda in the
"diffsummary" key. In preparation for enabling JSON output from hgweb,
teach the json filter how to call functions.
Matt Mackall <mpm@selenic.com> [Thu, 01 Jan 2015 16:47:14 -0600] rev 23706
merge with stable
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 24 Dec 2014 03:26:48 -0800] rev 23705
linkrev: also adjust linkrev when bootstrapping annotate (issue4305)
The annotate logic now use the new 'introrev' method to bootstrap its traversal.
This catches issues from linkrev-shadowing of the changeset introducing the
version of a file in source changeset.
More tests have been added to display pathological cases.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 29 Dec 2014 23:40:24 -0800] rev 23704
linkrev: also adjust linkrev when bootstrapping 'follow' revset
The follow revset (used by `hg log --follow`) now uses the new 'introrev'
method to bootstrap its traversal. This catches issues from linkrev-shadowing of
the changesets introducing the version of a file in source changeset.
A new test has been added to display pathological cases.
Another test is affected because it was meant to test this behavior but actually
failed to do so for half of the output. The output are now similar.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 23 Dec 2014 16:14:39 -0800] rev 23703
linkrev: introduce an 'introrev' method on filectx
The previous changeset properly fixed the ancestors computation, but we need to
ensure that the initial filectx is also using the right changeset.
When asking for log or annotation from a certain point, the first step is to
define the changeset that introduced the current file version. We cannot just
pick the "starting point" changesets as it may just "use" the file revision,
unchanged.
Currently, we were using 'linkrev' for this purpose, but this exposes us to
unexpected branch-jumping when the revision introducing the starting point
version is itself linkrev-shadowed. So we need to take the topology into
account again. Therefore, we introduce an 'introrev' function, returning the
changeset which introduced the file change in the current changeset.
This function will be used to fix linkrev-related issues when bootstrapping 'hg
log --follow' and 'hg annotate'.
It reuses the '_adjustlinkrev' function, extending it to allow introspection of
the initial changeset too. In the previous usage of the '_adjustlinkrev' the
starting rev was always using a children file revisions, so it could be safely
ignored in the search. In this case, the starting point is using the revision
of the file we are looking, and may be the changeset we are looking for.