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.
1---2name: pull3description: Pull (offline-demo)4---56# Pull (offline-demo)78There is no remote in this demo. "Pull" here means: bring local `main`9commits into the current feature branch.1011## Workflow12131. Verify a clean working tree. Commit or stash before merging.142. Enable rerere so conflict resolutions are remembered:15 ```sh16 git config rerere.enabled true17 git config rerere.autoupdate true18 ```193. Confirm you're on the feature branch (`symphony/<identifier>`), not on20 `main`:21 ```sh22 git branch --show-current23 ```244. Merge `main` into the current branch:25 ```sh26 git -c merge.conflictstyle=zdiff3 merge main27 ```285. If conflicts: resolve, `git add <files>`, `git commit`29 (or `git merge --continue`).306. Verify nothing was missed: `git diff --check`.3132Note: `git pull` and `git fetch origin` will both fail in this demo because33there is no `origin`. Use `git merge main` directly.3435## Conflict resolution3637- Inspect intent: `git status`, `git diff --merge`, and38 `git diff :1:path :2:path` (base vs ours), `git diff :1:path :3:path`39 (base vs theirs) for file-level views.40- With `merge.conflictstyle=zdiff3`, conflict markers show: `<<<<<<<` ours,41 `|||||||` base, `=======` split, `>>>>>>>` theirs. Matching context near42 the edges is trimmed automatically.43- Decide the **final intended behavior** first; only then craft the code.44- Prefer minimal, intention-preserving edits.45- Resolve one file at a time and rerun any local tests after each batch.46- Use `ours`/`theirs` only when one side should clearly win entirely.47- Generated files: resolve source first, then regenerate, then stage.48- Import conflicts: keep both temporarily, then prune via lint/typecheck.4950## When to ask the user5152Default: don't. Make a best-effort decision, document the rationale in the53merge commit, and proceed. Ask only when:5455- Resolution depends on product intent that isn't inferable from code/tests.56- A user-visible API contract is at stake.57- The merge introduces irreversible side effects (data loss, schema drops).58- The branch or remote isn't what you expected.
everyinc