This is the new API that Python has already migrated to.
Details
- Reviewers
- None
- Group Reviewers
hg-reviewers - Commits
- rHGa2b1767790e9: rust-dirstatemap: add `set_possibly_dirty` method
rHG5ded54dd1572: rust-dirstatemap: add `set_possibly_dirty` method
Diff Detail
- Repository
- rHG Mercurial
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Event Timeline
rust/hg-core/src/dirstate_tree/dirstate_map.rs | ||
---|---|---|
808 | I don't think this should affect anything. Setting an entry as possibly_dirty does not have any effect on its being tracked or having a copy source, or an entry. The next call to dirstate.status will use some other method to reset its state. Or am I missing something? |
rust/hg-core/src/dirstate_tree/dirstate_map.rs | ||
---|---|---|
808 | My question is more "it seems like this call could insert a node, yet nothing is done to adjust the counter associated to this insertion". Is this a legitimate concerns ? |
rust/hg-core/src/dirstate_tree/dirstate_map.rs | ||
---|---|---|
808 | This can't insert a node because of the check in the public function. There is a strong case to use get_node_mut instead, but it would have to be adjusted to have an ancestors callback as well. I propose to fix D12456 in the state that it is, and then add that change on top of the stack. |
rust/hg-core/src/dirstate_tree/dirstate_map.rs | ||
---|---|---|
808 | It seems like we are in a "This function is correct because *unrelated* code never call it with argument that makes it wrong" That seems dangerous, and either and assert or a narrower function use would be safer. Doing that fix at the top of the stack up seems fines if that helps. |
(Same question as in D12456)