mirror of
https://github.com/martinvonz/jj.git
synced 2025-05-31 23:25:09 +00:00
f70e6987b5
We write conflict to the working copy by materializing them as conflict markers in a file. When the file has been modified (or just the mtime has changed), we parse the markers to reconstruct the conflict. For example, let's say we see this conflict marker: ``` <<<<<<< +++++++ b %%%%%%% -a +c >>>>>>> ``` Then we will create a hunk with ["a"] as removed and ["b", "c"] as added. Now, since commit b84be06c0822, when we materialize conflicts, we minimize the diff part of the marker (the `%%%%%%%` part). The problem is that that minimization may result in a different order of the positive conflict terms. That's particularly bad because we do the minimization per hunk, so we can end up reconstructing an input that never existed. This commit fixes the bug by only considering the next add and the one after that, and emitting either only the first with `%%%%%%%`, or both of them, with the first one in `++++++++` and the second one in `%%%%%%%`. Note that the recent fix to add context to modify/delete conflicts means that when we parse modified such conflicts, we'll always consider them resolved, since the expected adds/removes we pass will not match what's actually in the file. That doesn't seem so bad, and it's not obvious what the fix should be, so I'll leave that for later.