@gitkraken/conflict-tools 0.7.1-beta.4 → 0.7.1-beta.6
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md
CHANGED
|
@@ -10,9 +10,11 @@ and this project adheres to [Semantic Versioning](https://semver.org/).
|
|
|
10
10
|
### Changed
|
|
11
11
|
|
|
12
12
|
- Merge conflicts now get `<upstream-commits>` fetched by the resolver: when `refs` are set and `upstreamCommits` is undefined, it lists the incoming branch's commits for the file (`base..theirs`), and the system prompt explains the block. Hosts that name no `operation` keep the old behavior. (#217)
|
|
13
|
+
- The resolver system prompt now tells the model up front to escape quotes, backslashes, newlines and tabs inside the JSON reply, and that the raw CDATA file content does not change that. This cuts parse rejections caused by unescaped `"` in chunk `content`. (#232)
|
|
13
14
|
|
|
14
15
|
### Fixed
|
|
15
16
|
|
|
17
|
+
- A delete-modify answer that takes the side which deleted the file (`ours` or `theirs`) is now treated as `deleted`. Before, it became a `take-ours`/`take-theirs` that `git checkout` could not apply, and `applyResolutions` threw for the whole batch. The resolver prompt now says to accept the deletion with `strategy "deleted"`. (#234)
|
|
16
18
|
- The resolver prompt prints file content (marker sides, context, user-resolved content, three-way diffs) verbatim inside CDATA sections instead of XML-escaping it, and tells the model not to add or decode entities. Merged chunks no longer come back with `<`, `>` or `&` in place of `<`, `>` and `&`. (#218)
|
|
17
19
|
|
|
18
20
|
## [0.7.0] - 2026-10-27
|
|
@@ -1 +1 @@
|
|
|
1
|
-
import{applyChunks as e}from"./chunk-apply.js";import{computeRawSignals as t}from"./raw-signals.js";function n(n,a,o){let s=
|
|
1
|
+
import{applyChunks as e}from"./chunk-apply.js";import{computeRawSignals as t}from"./raw-signals.js";function n(n,a,o){let s=n.type===`delete-modify`&&o.fileStrategy!==void 0&&o.fileStrategy===n.deletedBy?`deleted`:o.fileStrategy,c=a;s&&s!==`deleted`&&(c=n.markers.map((e,t)=>({markerIndex:t,strategy:s})));let l=o.description!==void 0&&o.description.trim().length>0?o.description:i(c),u;u=s===`deleted`?`deleted`:s?s===`ours`?`take-ours`:`take-theirs`:r(c);let d=s===`deleted`||c.length===0?``:e(n.rawContent,n.markers,c);return{filePath:n.filePath,content:d,strategy:u,confidence:o.confidence,description:l,chunks:c,...o.metrics?{metrics:o.metrics}:{},rawSignals:t(n,{threeWayDiff:o.threeWayDiff,stepCount:o.metrics?.stepCount,retryCount:o.metrics?.retryCount})}}function r(e){if(e.length===0)return`skipped`;let t=new Set(e.map(e=>e.strategy));if(t.size===1){if(t.has(`ours`))return`take-ours`;if(t.has(`theirs`))return`take-theirs`}return`ai`}function i(e){if(e.length===0)return`No markers resolved.`;let t=new Set(e.map(e=>e.strategy));if(t.size===1){if(t.has(`ours`))return`All markers resolved by taking ours.`;if(t.has(`theirs`))return`All markers resolved by taking theirs.`}return`Resolved ${e.length} marker(s) with mixed strategies.`}export{n as createResolution};
|
|
@@ -1 +1 @@
|
|
|
1
|
-
import{createResolution as e}from"./create-resolution.js";function t(t){return
|
|
1
|
+
import{createResolution as e}from"./create-resolution.js";function t(t){return e(t,[],{confidence:1,fileStrategy:`ours`})}function n(t){return e(t,[],{confidence:1,fileStrategy:`theirs`})}export{t as takeOurs,n as takeTheirs};
|
package/dist/resolver/prompt.js
CHANGED
|
@@ -67,6 +67,8 @@ Top-level fields:
|
|
|
67
67
|
- Good: "Insert the analytics import from theirs (line 12) below the existing logger import (line 7)."
|
|
68
68
|
- Bad: "Make sure both features are preserved somewhere appropriate."
|
|
69
69
|
|
|
70
|
+
JSON escaping: your reply is parsed by a strict JSON parser. Inside every string value — "content" above all — write a double quote as \\" , a backslash as \\\\ , a newline as \\n and a tab as \\t . The CDATA sections in the user message show file content raw so you can read it; that does not change how you must escape it in your reply.
|
|
71
|
+
|
|
70
72
|
Confidence scoring guide (applies to each chunk's "confidence", and to a file-level "strategy" confidence):
|
|
71
73
|
- 1.0: Trivial — only one side changed, or changes are in completely independent regions
|
|
72
74
|
- 0.8–0.9: Clear intent — both sides changed but intent is unambiguous from context
|
|
@@ -116,7 +118,7 @@ ${r?.length?`- The <file-guidance> block contains instructions selected specific
|
|
|
116
118
|
|
|
117
119
|
## Delete-Modify Conflicts
|
|
118
120
|
When the user message says "Delete-modify conflict", one side deleted the file while the other modified it. There are NO conflict markers — only the three-way diff is available.
|
|
119
|
-
- Default to the
|
|
121
|
+
- Default to accepting the deletion (strategy "deleted") — the deletion was intentional and the modifications are usually obsolete. The other side having modified the file is not by itself a reason to keep it. Keep the file only when its modifications add behaviour that the deleting side did not move elsewhere — check with grep or log before deciding.
|
|
120
122
|
- Keep the modified side ONLY when the three-way diff shows the modifications are clearly essential (e.g., the file is newly created, not just edited).
|
|
121
123
|
- To accept the deletion, respond with strategy "deleted". To keep the file, use strategy matching the modifying side.
|
|
122
124
|
- Cap confidence at 0.8 — delete-modify conflicts always carry some risk.
|