You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Interim patches for "left vs base" and "right vs base" are required. "op"=="test" can be ignored when combining the both patches to a 3-way-patch. If a "path" is touched by a single patch, then it can go directly to the 3-way-patch output. If a path is touched by both patches then it is a potential conflict. If "op" and "value" is equal on both patches then it is not a conflict and can be written as a single line to the 3-way-patch. Else it is a conflict and should be written like in the example:
This json-cli feature can help to write a 3-way-merge conflict auto resolver (wrapper script) e.g. for sops-encrypted json files.
On conflict this wrapper script can at least auto-merge non-conflicting changes and show the conflicts to the user for manual conflict resolution (e.g. via P4merge, KDiff3).
The text was updated successfully, but these errors were encountered:
{"op":"conflict"} does not belong to JSON Patch RFC, I think we should not be breaking RFC compliance for such purpose.
What do you think if such 3-way-diff implemented in two parts: non-conflicting diff (a regular RFC patch) and conflicts collection ([{"op":"conflict"},...])?
Alternative approach to consider is to json-cli rearrange and pretty print left.json and right.json from base.json. That way you will receive json files that can be resolved with regular text diff.
Could you elaborate the expected usecase scenario? Not sure I can clearly understand how would you use [{"op":"conflict"},...] later in tooling flow.
I would love to see a 3-way diff:
json-cli threewaydiff base.json left.json right.json
And to get a combined patch for non-conflicting changes:
Or in case of a conflict:
Interim patches for "left vs base" and "right vs base" are required. "op"=="test" can be ignored when combining the both patches to a 3-way-patch. If a "path" is touched by a single patch, then it can go directly to the 3-way-patch output. If a path is touched by both patches then it is a potential conflict. If "op" and "value" is equal on both patches then it is not a conflict and can be written as a single line to the 3-way-patch. Else it is a conflict and should be written like in the example:
This json-cli feature can help to write a 3-way-merge conflict auto resolver (wrapper script) e.g. for sops-encrypted json files.
On conflict this wrapper script can at least auto-merge non-conflicting changes and show the conflicts to the user for manual conflict resolution (e.g. via P4merge, KDiff3).
The text was updated successfully, but these errors were encountered: