mirror of
https://github.com/martinvonz/jj.git
synced 2024-12-27 06:27:43 +00:00
f4499aa65e
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. |
||
---|---|---|
.. | ||
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 | ||
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 | ||
test_rewrite.rs | ||
test_view.rs | ||
test_working_copy.rs | ||
test_working_copy_concurrent.rs | ||
test_working_copy_sparse.rs | ||
test_workspace.rs |