Pull

Conflict Resolution Guidance

• Inspect context before editing:
  • Use git status to list conflicted files.
  • Use git diff or git diff --merge to see conflict hunks.
  • Use git diff :1:path/to/file :2:path/to/file and git diff :1:path/to/file :3:path/to/file to compare base vs ours/theirs.
  • With merge.conflictstyle=zdiff3, focus on the differing core rather than matching context.
  • Summarize the intent of both sides before editing.
• Prefer minimal, intention-preserving edits.
• Resolve one file at a time and rerun tests after each logical batch.
• Use ours/theirs only when one side clearly wins in full.
• For generated files, resolve source conflicts first, then regenerate artifacts.
• After resolving, ensure no conflict markers remain:
  • git diff --check

When To Ask The User

Do not ask for input unless there is no safe, reversible alternative.

Ask only when:

• The correct resolution depends on product intent not inferable from code, tests, or documentation.
• The conflict crosses a user-visible API or migration where choosing incorrectly could break external consumers.
• The conflict requires selecting between two mutually exclusive designs with no clear local signal.
• The merge introduces data loss, schema changes, or irreversible side effects without an obvious safe default.
• The branch is not the intended target, or the remote/branch names do not exist and cannot be determined locally.

Otherwise, proceed with the merge, explain the decision briefly in notes, and leave a clear, reviewable history.