Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Jul 2021 04:32:31 +0200] rev 47598
mq: use `set_tracked` in `qrename`
This is the new shiny API.
Differential Revision: https://phab.mercurial-scm.org/D11018
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Jul 2021 03:42:14 +0200] rev 47597
mq: update the dirstate and its parent within a `parentchange` context
This is more correct, and move our plan of separated API for different dirstate
usage forward.
note: maybe the `parentchange` context manager should replace the dirstateguard
entirely ? (in this case we should probably deprecated dirstateguard).
Differential Revision: https://phab.mercurial-scm.org/D11017
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Jul 2021 01:20:46 +0200] rev 47596
context: use `dirstate.set_tracked` for `revert`
This is the new shiny API.
Differential Revision: https://phab.mercurial-scm.org/D11016
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Jul 2021 00:57:25 +0200] rev 47595
context: use `dirstate.set_tracked` in context.copy
This is the new shiny API.
Differential Revision: https://phab.mercurial-scm.org/D11015
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Jul 2021 00:58:44 +0200] rev 47594
context: use `dirstate.set_tracked` in `context.add`
This is the new shiny API.
Differential Revision: https://phab.mercurial-scm.org/D11014
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Jul 2021 03:03:34 +0200] rev 47593
dirstate: add a `set_tracked` method for "hg add"-like usage
This is a step further toward clarifying the semantic of various dirstate call.
Having a dedicated function comes with a couple of benefits:
1) we can move duplicated logic about how to handle the previous state within
the dirstate. Since we are sure this is always called in the same situation, we
can implement that logic once in the dirstate.
2) having a dedicated method for this case unlock also having a dedicated
method for the other case and recording more information at that time. All this
leading having more code within the dirstate and higher level API that are less
error prone.
Differential Revision: https://phab.mercurial-scm.org/D11013
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 10 Jul 2021 23:31:51 +0200] rev 47592
dirstate: add a function to update tracking status while "moving" parents
The `scmutil.dirstateparent` is moving the dirstate parent without touching the
working copy. It is used by history-rewriting operations like amending of
folding.
The function was directly doing the "low level" computation and dirstate
change. All that logic belong to the dirstate and should be moved there.
For this purpose we introduce a new function that does just that and use it.
Differential Revision: https://phab.mercurial-scm.org/D11012
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Jul 2021 10:05:23 +0200] rev 47591
dirstate: introduce an internal `_drop` method
We want to split current user of `dirstate.drop` between `hg rm`-like cases and
update of the dirstate coming from update/merge.
To do this we will introduce new API. The first step is to introduces an
internal function that these new API migh use (or not use) to distinct between
the migrated users and the others.
Differential Revision: https://phab.mercurial-scm.org/D11023
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 07 Jul 2021 19:32:22 +0200] rev 47590
dirstate: introduce an internal `_remove` method
We want to split current user of `dirstate.remove` between `hg rm`-like cases and
update of the dirstate coming from update/merge.
To do this we will introduce new API. The first step is to introduces an
internal function that these new API migh use (or not use) to distinct between
the migrated users and the others.
Differential Revision: https://phab.mercurial-scm.org/D11011
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 07 Jul 2021 19:31:52 +0200] rev 47589
dirstate: introduce an internal `_add` method
We want to split current user of `dirstate.add` between `hg add`-like cases and
update of the dirstate coming from update/merge.
To do this we will introduce new API. The first step is to introduces an
internal function that these new API migh use (or not use) to distinct between
the migrated users and the others.
Differential Revision: https://phab.mercurial-scm.org/D11010
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 09 Jul 2021 22:37:24 +0200] rev 47588
run-tests: rely on an actual executable in PATH instead of alias for `hg`
The alias approach is poorly inherited by other process that the test might
spawn.
To solve this we use the same approach as for `python`/`python3` we write an
executable file explicitly. Doing this fixes `which hg` invocation that now
returns the same location as `hg`.
Using chg server side has some minor effect on some stdout/stderr ordering when
using `chg` as the server too.
Differential Revision: https://phab.mercurial-scm.org/D11053
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 09 Jul 2021 20:42:26 +0200] rev 47587
tests: blacklist a handful of test with `rhg` or `chg`
The use of `alias` to enforce `chg` and `rhg` means we are actually using a mix
of `rhg`/`chg` and `hg` when calling `hg` in the test. Fixing this breaks
various tests. This would be a large detour to fix that. I am disabling
them for now with an appropriate comment.
We would hopefully get back to them by the 5.8 release.
Differential Revision: https://phab.mercurial-scm.org/D11052