| name | pull |
| description | Merge local `main` into the current branch and resolve merge conflicts |
Pull (offline-demo)
There is no remote in this demo. "Pull" here means: bring local main
commits into the current feature branch.
Workflow
- Verify a clean working tree. Commit or stash before merging.
- Enable rerere so conflict resolutions are remembered:
git config rerere.enabled true
git config rerere.autoupdate true
- Confirm you're on the feature branch (
symphony/<identifier>), not on
main:
git branch --show-current
- Merge
main into the current branch:
git -c merge.conflictstyle=zdiff3 merge main
- If conflicts: resolve,
git add <files>, git commit
(or git merge --continue).
- Verify nothing was missed:
git diff --check.
Note: git pull and git fetch origin will both fail in this demo because
there is no origin. Use git merge main directly.
Conflict resolution
- Inspect intent:
git status, git diff --merge, and
git diff :1:path :2:path (base vs ours), git diff :1:path :3:path
(base vs theirs) for file-level views.
- With
merge.conflictstyle=zdiff3, conflict markers show: <<<<<<< ours,
||||||| base, ======= split, >>>>>>> theirs. Matching context near
the edges is trimmed automatically.
- Decide the final intended behavior first; only then craft the code.
- Prefer minimal, intention-preserving edits.
- Resolve one file at a time and rerun any local tests after each batch.
- Use
ours/theirs only when one side should clearly win entirely.
- Generated files: resolve source first, then regenerate, then stage.
- Import conflicts: keep both temporarily, then prune via lint/typecheck.
When to ask the user
Default: don't. Make a best-effort decision, document the rationale in the
merge commit, and proceed. Ask only when:
- Resolution depends on product intent that isn't inferable from code/tests.
- A user-visible API contract is at stake.
- The merge introduces irreversible side effects (data loss, schema drops).
- The branch or remote isn't what you expected.