Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 03 Jul 2021 20:34:09 +0200] rev 47516
dirstate-entry: `merged_removed` and `from_p2_removed` properties
Lets start to define and use more semantic property. These two might be a bit
too low level and could be shaved off later, however this seems an improvement
for now.
Differential Revision: https://phab.mercurial-scm.org/D10958
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 03 Jul 2021 04:18:54 +0200] rev 47515
dirstate-entry: add a `removed` property
Lets start to define and use more semantic property.
Differential Revision: https://phab.mercurial-scm.org/D10957
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 03 Jul 2021 04:26:28 +0200] rev 47514
dirstate-entry: add a `from_p2` property
Lets start to define and use more semantic property.
Differential Revision: https://phab.mercurial-scm.org/D10956
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 03 Jul 2021 04:07:21 +0200] rev 47513
dirstate-entry: add a `merged` property
Lets start to define and use more semantic property.
Differential Revision: https://phab.mercurial-scm.org/D10955
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 04 Jul 2021 03:29:20 +0200] rev 47512
dirstate-entry: add a `state` property (and use it)
This replace the [0] access. Ultimately is we should probably get ride of this
in its current form. However this is a good transitional solution to move away
for tuple indexing for now.
Differential Revision: https://phab.mercurial-scm.org/D10954
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 03 Jul 2021 19:52:00 +0200] rev 47511
dirstate: move most of the `remove` logic with dirstatemap `removefile`
This code deal with special logic to preserving "merged" and "from_p2" information when removing a file. These are implementation details that are more suitable for the dirstatemap layer. Since the dirstatemap layer alreaday have most of the information necessary to do so, the move is easy.
This move helps us to encapsulate more implementation details within the dirstatemap and its entry. Easing the use of a different storage for dirstate v2.
Differential Revision: https://phab.mercurial-scm.org/D10953
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 03 Jul 2021 20:12:46 +0200] rev 47510
dirstate: add a `in_merge` property
This factor the "p2 is not null" check and is fairly simpler to read.
Differential Revision: https://phab.mercurial-scm.org/D10952
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 03 Jul 2021 04:01:17 +0200] rev 47509
dirstate-entry: introduce dedicated accessors for v1 serialization
In the spirit of changing the content and storage of the dirstate entry, we add
new method that the code doing v1 serialisation can use.
Adding such method to the C object is quite trivial.
Differential Revision: https://phab.mercurial-scm.org/D10951
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 03 Jul 2021 03:55:23 +0200] rev 47508
dirstate-entry: goes through the `dirstatetuple` constructor in all cases
We need to make sure we build an object.
Differential Revision: https://phab.mercurial-scm.org/D10950
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 03 Jul 2021 03:48:35 +0200] rev 47507
dirstate-entry: turn dirstate tuple into a real object (like in C)
With dirstate V2, the stored information and actual format will change. This mean we need to start an a better abstraction for a dirstate entry that a tuple directly accessed.
By chance, the C code is already doing this and pretend to be a tuple. So it
should be fairly easy. We start with turning the tuple into an object, we will
slowly migrate the dirstate code to no longer use the tuple directly in later
changesets.
Differential Revision: https://phab.mercurial-scm.org/D10949