Fri, 06 Oct 2017 17:53:36 +0200 obsfate: add obsfate to default mapfile
Boris Feld <boris.feld@octobus.net> [Fri, 06 Oct 2017 17:53:36 +0200] rev 34853
obsfate: add obsfate to default mapfile Use the verbosity aware template keyword introduced earlier. It has the nice property of being verbosity dependent but in order to customize the obsfate part, users will need to replace the lobsfate definition from default mapfile with the one using template functions (by copying the one from test-obsmarker- template.t for example). As it's a more advanced use-case, I'm more inclined to have the same code for the {obsfate} keyword, in the changeset printer and in the default mapfile for consistency. But, the definition in default mapfile could be replaced with one based on template filter to obsfate output customization if it is a big need for users.
Thu, 05 Oct 2017 15:25:18 +0200 log: add obsfate by default in changeset printer
Boris Feld <boris.feld@octobus.net> [Thu, 05 Oct 2017 15:25:18 +0200] rev 34852
log: add obsfate by default in changeset printer Having an obsfate by default in log will be useful for users to understand why they have obsolete and unstable changesets. Obsfate will only be shown for obsolete changesets, which only happens if people opt-in to experimental feature. But when obsolete changeset are visible, it is very useful to understand where they are. Having it in log could be sufficient for most people, so they don't have to learn a new command (like obslog which is itself useful in case of divergences). For example, when pulling and working directory parent become obsolete: $ hg pull ... working directory parent is obsolete! (f936c1697205) This message comes from the Evolve extension. Obsfate would comes handy: $ hg log -G o changeset: 2:6f91013c5136 | tag: tip | parent: 0:4ef7b558f3ec | user: Boris Feld <boris.feld@octobus.net> | date: Mon Oct 09 16:00:27 2017 +0200 | summary: A | | @ changeset: 1:f936c1697205 |/ user: Boris Feld <boris.feld@octobus.net> | date: Mon Oct 09 16:00:27 2017 +0200 | obsfate: rewritten using amend as 2:6f91013c5136 | summary: -A | o changeset: 0:feb4dd822b8c user: Boris Feld <boris.feld@octobus.net> date: Tue Oct 09 16:00:00 2017 +0200 summary: ROOT And once we update, we don't have an obsolete changeset in the log anymore so we don't show obsfate anymore, most users won't see obsfate often if they don't have obsolete changeset often: @ changeset: 2:6f91013c5136 | tag: tip | parent: 0:4ef7b558f3ec | user: Boris Feld <boris.feld@octobus.net> | date: Mon Oct 09 16:00:27 2017 +0200 | summary: A | o changeset: 0:feb4dd822b8c user: Boris Feld <boris.feld@octobus.net> date: Tue Oct 09 16:00:00 2017 +0200 summary: ROOT
Mon, 09 Oct 2017 15:34:26 +0200 obsfate: only display date in verbose mode
Boris Feld <boris.feld@octobus.net> [Mon, 09 Oct 2017 15:34:26 +0200] rev 34851
obsfate: only display date in verbose mode The date is also not that helpful in most cases but we show it in verbose mode.
Mon, 09 Oct 2017 15:34:12 +0200 obsfate: filter out current user if not in verbose
Boris Feld <boris.feld@octobus.net> [Mon, 09 Oct 2017 15:34:12 +0200] rev 34850
obsfate: filter out current user if not in verbose Obsolescence is sometimes used only locally so the obs-marker users is always the same. Showing the user in this case does not bring much values. In the case where multiple users rewrite the commit, display the full list of users. Also show all users in verbose mode.
Fri, 06 Oct 2017 16:23:47 +0200 ui: add the possibility to returns None as username in ui
Boris Feld <boris.feld@octobus.net> [Fri, 06 Oct 2017 16:23:47 +0200] rev 34849
ui: add the possibility to returns None as username in ui In a later patch we want to retrieve the current username or None if it isn't defined. Add the acceptempty parameter instead of catching Abort.
Fri, 06 Oct 2017 17:15:49 +0200 test: test obfate template keyword in test-obsmarker-template.t
Boris Feld <boris.feld@octobus.net> [Fri, 06 Oct 2017 17:15:49 +0200] rev 34848
test: test obfate template keyword in test-obsmarker-template.t These test updates are pretty big by themselves so put it in a separate patch for easing the review process.
Thu, 05 Oct 2017 17:42:56 +0200 templatekw: introduce obsfate keyword
Boris Feld <boris.feld@octobus.net> [Thu, 05 Oct 2017 17:42:56 +0200] rev 34847
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"}")}
Tue, 10 Oct 2017 02:25:03 +0530 copies: add a config to limit the number of candidates to check in heuristics
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 10 Oct 2017 02:25:03 +0530] rev 34846
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
Tue, 17 Oct 2017 10:31:44 -0700 extensions: always include traceback when extension setup fails
Martin von Zweigbergk <martinvonz@google.com> [Tue, 17 Oct 2017 10:31:44 -0700] rev 34845
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
Tue, 17 Oct 2017 10:25:32 -0700 tests: move baduisetup() test out of "#if demandimport"
Martin von Zweigbergk <martinvonz@google.com> [Tue, 17 Oct 2017 10:25:32 -0700] rev 34844
tests: move baduisetup() test out of "#if demandimport" It no longer depends on demandimport. Differential Revision: https://phab.mercurial-scm.org/D1163
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip