For example, copy source are handled separately. Removing it goes through
the copy_map_remove method (exposed to Python as .copymap.pop())
Details
- Reviewers
Alphare - Group Reviewers
hg-reviewers - Commits
- rHGf6d0a89fdf80: dirstate: Don’t drop unrelated data in DirstateMap::set_entry
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
This is called by dirstatemap.py:
- In set_tracked when an entry already existed but wasn’t tracked (for example hg add just after hg rm)
- In set_possibly_dirty
- In __setitem__
- (And in set_clean, but that one also calls copymap().pop(filename) anyway)
So my guess as to why no test was affected is that this isn’t called super often, and most tests don’t also check copy tracing information. It would be good to have a CLI-level integration test that’s affected by this but I don’t know how to make one. When and how are used copy source info stored in the dirstate?
I would not be in favor of adding dirstatemap.py unit tests (at least at the moment) because it’s an internal API that keep changing. As to a low-level unit test for this specific DirstateMap::set_entry Rust method, I feel it could only be trivial like "1. Do X 2. Check X is done" and not helpful at finding actual bugs. What matters here is what semantics are expected or not by callers.
When using hg move or hg copy, basically. It stores the copy information in the dirstate, and it gets committed at the next hg commit
I would not be in favor of adding dirstatemap.py unit tests (at least at the moment) because it’s an internal API that keep changing. As to a low-level unit test for this specific DirstateMap::set_entry Rust method, I feel it could only be trivial like "1. Do X 2. Check X is done" and not helpful at finding actual bugs. What matters here is what semantics are expected or not by callers.
Agreed.
Does that mean that a file can only ever have a copy source in the dirstate if it is in "added" state?
No, because it can be marked as a copy after the fact with hg mv --after for example.
I’m struggling coming up with a test case that shows different behavior with this patch. I’ve found how to have copy_source != None for some dirstate nodes, but not what hg command can cause this set_entry method to be called for the same node after that.