- Sep 30, 2018
-
-
Yuya Nishihara authored
I think {lineno} looks more like a common template keyword. It isn't called a {line} to avoid conflicts with the element name of {lines} and the {_|splitlines} filter. https://www.mercurial-scm.org/wiki/GenericTemplatingPlan#Dictionary
-
- Sep 15, 2018
-
-
Yuya Nishihara authored
This is a part of the unification series. The 'ff..' hash is preferred over None as it is a valid revision specifier. https://www.mercurial-scm.org/wiki/GenericTemplatingPlan#Sanity_check_output
-
- Sep 19, 2018
-
-
Matt Harbison authored
Python3 defaults to installing under "Program Files".
-
- Aug 05, 2018
-
-
Yuya Nishihara authored
Note that {path} in status is either relative-to-cwd or repository-absolute depending on the command argument and config knob, which can't be reproduced by using the {path|relpath} filter. The default template is updated to always use a relative path. .. bc:: ``{abspath}`` and ``{file}`` in generic templates are renamed to ``{path}``. Any ``{path}`` is a repository-absolute path. Use ``{path|relpath}`` to convert it to a filesystem path.
-
- Jun 18, 2018
-
-
Yuya Nishihara authored
Otherwise symbolsused() would fail if a named template is specified with -T.
-
- May 03, 2018
-
-
Yuya Nishihara authored
If '{line_number}' is in the template, we'll probably need it. No --line-number option should be required in such cases.
-
- Mar 17, 2018
-
-
Yuya Nishihara authored
-
- Mar 15, 2018
-
-
Yuya Nishihara authored
-
- Apr 02, 2018
-
-
Gregory Szorc authored
Debug commands operating on revlogs don't need the full revlog path: they can accept the relative path to a tracked file or use -c/-m to specify a changelog or manifest. Not using the revlog path makes tests more resilient to cases where revlogs aren't being used for storage. Differential Revision: https://phab.mercurial-scm.org/D3025
-
- Mar 24, 2018
-
-
Yuya Nishihara authored
-
- Mar 11, 2018
-
-
Yuya Nishihara authored
-
- Mar 10, 2018
-
-
Yuya Nishihara authored
-
- Mar 06, 2018
-
-
Gregory Szorc authored
There were a handful of merge conflicts in the wire protocol code due to significant refactoring in default. When resolving the conflicts, I tried to produce the minimal number of changes to make the incoming security patches work with the new code. I will send some follow-up commits to get the security patches better integrated into default.
-
- Mar 04, 2018
-
-
Yuya Nishihara authored
-
Yuya Nishihara authored
I hope this will fix the test failure seen on FreeBSD and Windows.
-
Augie Fackler authored
-
- Mar 03, 2018
-
-
Ryan McElroy authored
This logic is largely based on the similar logic added to template error messages in D2608 and D2609, but with a few tweaks based on how revsets actually work. Differential Revision: https://phab.mercurial-scm.org/D2619
-
- Feb 21, 2018
-
-
Yuya Nishihara authored
mdiff and lines(text) take only LF as a line separator, but str.splitlines() breaks our assumption. Use mdiff.splitnewlines() consistently. It's hard to read \r in tests, so \r is replaced with [CR]. I had to wrap sed by a shell function to silence check-code warning.
-
- Dec 03, 2017
-
-
Matt Harbison authored
Automatic replacement seems better than trying to figure out a check-code rule. I didn't bother looking to see why the error message and file name is reversed in the annotate and histedit tests, based on Windows or not. I originally had this as a list of tuples, conditional on the platform. But there are a couple of 'No such file or directory' messages emitted by Mercurial itself, so unconditional is required for stability. There are also several variants of what I assume is 'connection refused' and 'unknown host' in test-clone.t and test-clonebundles.t for Docker, FreeBSD jails, etc. Yes, these are handled by (re) tags, but maybe it would be better to capture those strings in order to avoid whack-a-mole in future tests. All of this points to using a dictionary containing one or more strings-to-be-replaced values.
-
- Oct 05, 2017
-
-
Augie Fackler authored
This is just a side effect of surfacing the "revisions were skipped" state in the blame output. Differential Revision: https://phab.mercurial-scm.org/D956
-
- Oct 02, 2017
-
-
Siddharth Agarwal authored
This is to prevent weird surprises from happening with skips being attributed to the wrong changeset. .. feature:: `hg annotate --skip` now prints a `*` on lines with skipped revisions Differential Revision: https://phab.mercurial-scm.org/D900
-
- Aug 22, 2017
-
-
durin42 authored
-
- Jul 08, 2017
-
-
Yuya Nishihara authored
The proposed syntax [1] was originally 'set{n rel}', but it seemed slightly confusing if template is involved. On the other hand, we want to keep 'set[n]' for future extension. So this patch introduces 'set#rel[n]' ternary operator. I chose '#' just because it looks like applying an attribute. This also adds stubs for 'set[n]' and 'set#rel' operators since these syntax elements are fundamental for constructing 'set#rel[n]'. [1]: https://www.mercurial-scm.org/wiki/RevsetOperatorPlan#ideas_from_mpm
-
Matt Harbison authored
-
- Jul 05, 2017
-
-
Denis Laxalde authored
In blockdescendants(), we had an assertion when line range of a merge changeset was not consistent depending on which parent was considered for computation. For instance, this might occur when file content (in lookup range) is significantly different between parent branches of the merge as demonstrated in added tests (where we almost completely rewrite the "baz" file while also introducing similarities with its content in the other branch we later merge to). Now, in such case, we combine line ranges from all parents by storing the envelope of both line ranges. This is conservative (the line range is extended, possibly unnecessarily) but at least this should avoid missing descendants with changes in a range that would fall in that of one parent but not in another one (the case of "baz: narrow change (2->2+)" changeset in tests).
-
- Jun 10, 2017
-
-
durin42 authored
I'm pretty sure that both results are valid, depending on how you slice the edits.
-
- Jun 02, 2017
-
-
Yuya Nishihara authored
Annotate data should be in [(file, [line...])...] form, but there was no API to represent such data structure when I ported it to formatter. Now we have fm.nested() and the -T option is still experimental, so we can fix the data format.
-
- May 25, 2017
-
-
Siddharth Agarwal authored
This option is most useful for mechanical code modifications, especially ones that retain the same number of lines.
-
- Apr 30, 2017
-
-
Katsunori FUJIWARA authored
This patch also includes un-quoting "descend" keyword for similarity to other error messages (this seems too trivial as a separated patch).
-
- Apr 20, 2017
-
-
Denis Laxalde authored
Previously, calling blockancestors() with a fctx not touching file would sometimes yield this filectx first, instead of the first "block ancestor", because when compared to its parent it may have changes in specified line range despite not touching the file at all. Fixing this by starting the algorithm from the "base" filectx obtained using fctx.introrev() (as done in annotate()). In tests, add a changeset not touching file we want to follow lines of to cover this case. Do this in test-annotate.t for followlines revset tests and in test-hgweb-filelog.t for /log/<rev>/<file>?linerange=<from>:<to> tests.
-
- Apr 15, 2017
-
-
Denis Laxalde authored
We parse "descend" symbol as a Boolean using getboolean (prior extraction by getargsdict already checked that it is a symbol). In tests, check for error cases and vary Boolean values here and there.
-
- Apr 14, 2017
-
-
Denis Laxalde authored
If initial 'fctx' has changes in line range with respect to its parents, we yield it first. This makes 'followlines(..., descend=True)' consistent with 'descendants()' revset which yields the starting revision. We reuse one iteration of blockancestors() which does exactly what we want. In test-annotate.t, adjust 'startrev' in one case to cover the situation where the starting revision does not touch specified line range.
-
Denis Laxalde authored
If this assertion fails, this indicates a flaw in the algorithm. So fail fast instead of possibly producing wrong results. Also extend the target line range in test to catch a merge changeset with all its parents.
-
Denis Laxalde authored
In the initial implementation of blockdescendants (and thus followlines(..., descend=True) revset), only the first branch encountered in descending direction was followed. Update the algorithm so that all children of a revision ('x' in code) are considered. Accordingly, we need to prevent a child revision to be yielded multiple times when it gets visited through different path, so we skip 'i' when this occurs. Finally, since we now consider all parents of a possible child touching a given line range, we take care of yielding the child if it has a diff in specified line range with at least one of its parent (same logic as blockancestors()).
-
- Jan 16, 2017
-
-
Denis Laxalde authored
This is useful to follow changes in a block of lines forward in the history (for instance, when one wants to find out how a function evolved from a point in history). We added a 'descend' parameter to followlines(), which defaults to False. If True, followlines() returns descendants of startrev. Because context.blockdescendants() does not follow renames, these are not followed by the revset either, so history will end when a rename occurs (as can be seen in tests).
-
- Jan 09, 2017
-
-
Yuya Nishihara authored
This slightly complicates the parsing (see the previous patch), but the overall result seems not bad. I keep x:, :y and : for future extension.
-
Yuya Nishihara authored
The rev argument has the same meaning as startrev of follow(), and I think startrev is more informative. followlines() is new function, we can make BC now.
-
Yuya Nishihara authored
-
- Jan 04, 2017
-
-
Denis Laxalde authored
This revset returns the history of a range of lines (fromline, toline) of a file starting from `rev` or the current working directory. Added tests in test-annotate.t which already contains a reasonably complex repository.
-
- Nov 15, 2016
-
-
Mads Kiilerich authored
[This change could be folded into the previous changeset to minimize the repo churn ...] The general preference to matches in the middle of bdiff ranges helps getting balanced recursion and efficient computation. But, as previous changes have shown, it might also give diffs that seems "obviously wrong". To mitigate that: If the best match on the A side starts at the beginning of the bdiff range, don't aim for the middle-most B side match but for the earliest. This will make the matches balanced (by both sides being "early") even though the bisection will be less balanced. Still, this case only apply if the *best* and middle-most match was fully unbalanced on the A side. Each recursion will thus even in this worst case reduce the problem significantly and we are not re-introducing the problem that was fixed in f1ca249696ed. The bundle size for 4.0 (hg bundle --base null -r 4.0 x.hg) happens to go from 22806817 to 22807275 bytes - a 0.002% increase. This make the recent test-bdiff.py changes give a more pretty output ... but they no longer show that the recursion is around middle matches (because it in these cases isn't).
-