templatekw: introduce obsfate keyword
Introduce an obsfate printer that uses all helpers functions defined in
obsutil to get all the obsfate-related data and format a string according to
the current format in test-obsmarker-template.t.
Then, introduce an obsfate templatekw that uses the obsfateprinter to return a
list of strings.
The goal is not to replace existing obsfate template functions but to propose
a default, good-enough and easily usable obsfate definition for end-users that
don't want to customize it. Such output would ultimately get included in the
default log output.
Here are some output examples for a commit amended:
rewritten using amend as 5:
a9b1f8652753 by test (at 1970-01-01 00:00 +0000)
Next patches will make the output dependent on the verbosity.
Exemple of use-cases:
For having the obsfate on a single-line between brackets:
{if(obsfate, " [{join(obsfate, "; ")}]")}
For having the obsfate in several lines:
{if(obsfate, "{obsfate % " Obsfate: {fate}\n"}")}
copies: add a config to limit the number of candidates to check in heuristics
The heuristics algorithm find possible candidates for move/copy and then check
whether they are actually a copy or move. In some cases, there can be lot of
candidates possible which can actually slow down the algorithm.
This patch introduces a config option
`experimental.copytrace.movecandidateslimit` using which one can limit the
candidates to check. The limit defaults to 100.
Thanks to Yuya for suggesting to skip copytracing for that file with a
warning.
Differential Revision: https://phab.mercurial-scm.org/D987
extensions: always include traceback when extension setup fails
I have spent a lot of time debugging extensions that failed to load
because we don't include a traceback and I didn't realize I could get
traceback for the extension failure with --traceback. Let's just turn
them on by default, since it should be rare that the user sees these
tracebacks anyway (and if they do, it's not so bad if the extra
traceback pushes them a little harder to report the problem).
Since we already had a test case with --traceback and one without, I
just removed the one with the flag.
Differential Revision: https://phab.mercurial-scm.org/D1164
tests: move baduisetup() test out of "#if demandimport"
It no longer depends on demandimport.
Differential Revision: https://phab.mercurial-scm.org/D1163
tests: make test-extension.t's baduisetup.py test fail even if bdiff exists
A mercurial.bdiff module has existed at some point and when I have
built at an old version, some .pyc file or something seems to stick
around and test-extension.t fails. Let's remove the reference to bdiff
and simplify the test.
Differential Revision: https://phab.mercurial-scm.org/D1162
run-tests: move newline out of colorized message
The leading newline before "ERROR:" led to an incorrect lexing of the
message and the newline got lost.
The fixed formatting can be seen in the test case. The reason we
didn't notice before was that the bad formatting just led to the loss
of a blank line in the test. However, there are other cases where it
would be joined with a line saying "Accept this change? [n]" or
"Reference output has changed (run again to prompt changes)".
Differential Revision: https://phab.mercurial-scm.org/D1159
test-extension: make the test compatible with chg
This test fails when run with chg. This commit just makes the test chg
aware by fixing the output of some of the tests.
Test Plan:
Ran the test 'test-extension.t' with and without '--chg' option.
Differential Revision: https://phab.mercurial-scm.org/D1160
hghave: disable demandimport when chg is running
Chg disables demandimport on purpose for performance wins and
therefore, it probably makes sense to indicate that demandimport is disabled
when chg is running.
Test Plan:
Ran all the tests.
Differential Revision: https://phab.mercurial-scm.org/D1161