Martin von Zweigbergk f4499aa65e conflicts: fix bug when modifying modify/delete conflicts ... Currently, if the user modifies a modify/delete conflict, we always consider the result resolved. That happens because we materialize the missing side of the conflict as an empty string but when we parse the conflict, we expect only the number of sides in the input conflict. For example, if the input is a regular modify/delete conflict with one remove and one add, the materialized markers will have one remove and two adds (one of them empty), but when we try to parse it, we expect one remove and only one add. When we fail to parse it, we consider it resolved. This commit fixes the bug by using `conflicts::Conflict<Option<TreeValue>>` and keeping track of which sides were supposed to be empty. We could have fixed the bug without switching to `conflicts::Conflict`, but we want to switch anyway, and the fix happens naturally when switching.		2023-06-04 06:48:34 -07:00
..
test_bad_locking.rs
test_commit_builder.rs
test_commit_concurrent.rs
test_conflicts.rs
test_default_revset_graph_iterator.rs
test_diff_summary.rs
test_git.rs
test_id_prefix.rs	id_prefix: remove repo field from IdPrefixContext	2023-05-11 23:41:24 -07:00
test_index.rs
test_init.rs
test_load_repo.rs
test_merge_trees.rs
test_mut_repo.rs
test_operations.rs
test_refs.rs
test_revset.rs	revset: use different errors for ambiguous commit/change IDs	2023-05-31 06:28:32 -07:00
test_rewrite.rs	repo: extract a Repo trait for Arc<ReadonlyRepo> and MutableRepo	2023-02-15 19:15:17 -08:00
test_view.rs
test_working_copy.rs
test_working_copy_concurrent.rs
test_working_copy_sparse.rs
test_workspace.rs