Tue, 28 Sep 2021 13:59:01 -0700 errors: raise InputError from revpair() iff revset provided by the user
Martin von Zweigbergk <martinvonz@google.com> [Tue, 28 Sep 2021 13:59:01 -0700] rev 48117
errors: raise InputError from revpair() iff revset provided by the user Same reasoning as for `revrange()` in an earlier patch. Differential Revision: https://phab.mercurial-scm.org/D11561
Tue, 28 Sep 2021 08:47:11 -0700 errors: raise InputError on bad revset to revrange() iff provided by the user
Martin von Zweigbergk <martinvonz@google.com> [Tue, 28 Sep 2021 08:47:11 -0700] rev 48116
errors: raise InputError on bad revset to revrange() iff provided by the user Most callers of `scmutil.revrange()` pass in a revset provided by the user. If there are problems resolving that, it should result in an `InputError` and exit code 10 (when using detailed exit codes). However, there are also some callers that pass in revsets not provided by the user. `InputError` is not appropriate in those cases. This patch therefore introduces a wrapper around `scmutil.revrange()` that simply converts the exception type. I put it in `logcmdutil.py` since that seems to be the lowest-level module in the (poorly defined) UI layer. Differential Revision: https://phab.mercurial-scm.org/D11560
Tue, 28 Sep 2021 09:08:43 -0700 phase: avoid a no-op resolution of revset from revnums
Martin von Zweigbergk <martinvonz@google.com> [Tue, 28 Sep 2021 09:08:43 -0700] rev 48115
phase: avoid a no-op resolution of revset from revnums I was surprised that `scmutil.revrange()` supports integers in the list of revsets. I think it's clearer to not pass a list that's known to contain only integers into the function. Differential Revision: https://phab.mercurial-scm.org/D11559
Fri, 01 Oct 2021 15:19:37 +0200 dirstate: push back the future a bit in the test
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 15:19:37 +0200] rev 48114
dirstate: push back the future a bit in the test The future was set to 2021-01-01, we push it by 10 years.
Thu, 30 Sep 2021 18:07:31 +0200 dirstate-item: point out that `merged` is set only with p1_tracked
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 30 Sep 2021 18:07:31 +0200] rev 48113
dirstate-item: point out that `merged` is set only with p1_tracked This is currently True, and we will use this fact to simplify the API in the next commit. However, we add this assertion first to validate that this is True in the whole test-suite.
Wed, 29 Sep 2021 01:23:10 +0200 dirstate-item: update the attribute documentation
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 29 Sep 2021 01:23:10 +0200] rev 48112
dirstate-item: update the attribute documentation It was very outdated. We are about to change these attribute so we should has well have them documented so that the change get easier to grasp.
Fri, 01 Oct 2021 03:50:37 +0200 dirstate-item: use `any_tracked` more
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 03:50:37 +0200] rev 48111
dirstate-item: use `any_tracked` more This simplify more code.
Fri, 01 Oct 2021 03:49:03 +0200 dirstate-item: drop an outdated comments
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 03:49:03 +0200] rev 48110
dirstate-item: drop an outdated comments This comment is no longer relevant since we moved away from the `state` internal representation, multiple weeks ago.
Fri, 01 Oct 2021 00:00:29 +0200 dirstate: remove a update_file's special case for `merged` file
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 00:00:29 +0200] rev 48109
dirstate: remove a update_file's special case for `merged` file This case was fishy and can be dealt with by passing more accurate data a higher level. This clarify the API and prepare for a larger rework of the data we feeds to the dirstate.
Thu, 30 Sep 2021 18:00:39 +0200 dirstate: remove a update_file's special case for tracked file with p2 data
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 30 Sep 2021 18:00:39 +0200] rev 48108
dirstate: remove a update_file's special case for tracked file with p2 data This case was fishy and can be dealt with by passing more accurate data a higher level. This clarify the API and prepare for a larger rework of the data we feeds to the dirstate.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip