gitextensions Deep Explanation
Produce an accurate, grounded explanation — never hand-wave.
Phase 1 — Become a mini-SME first (BLOCKING)
STOP — before explaining, ground yourself:
- Read the L0 primer.
- Open the master docs-index, pick the matching reading chain, and read those docs in order (L1 concept → L2 subsystem → L3 flow).
- Verify against source — open the actual
src/files the docs point to. Docs give the "why"; the code confirms the "how".
Phase 2 — Explain with structure
Use Why → What → How:
- Why — the motivation/design rationale (from the docs).
- What — the components/actors and how they connect.
- How — the concrete path, with code pointers (
ClassName/Method/ file links) the reader can open. Prefer pointers over pasted code.
Include a compact Mermaid diagram for multi-step flows (sequence or graph). Label the execution context (UI thread vs background) where it matters — see threading-model.
Phase 3 — Close the loop
- Note cross-tier hops explicitly (UI →
GitUICommands→Commands/GitModule→git). - Call out quirks/gotchas the code reveals (e.g. legacy
ArgumentStringvsIGitCommand). - End with pointers to the exact files to read next.
Hard rules
- NEVER state a class/method/flow you haven't verified in source or a DAG doc.
- Ground every claim in a code pointer or a doc reference.
- Keep it scannable: lead with a 2–3 line summary, then the structured explanation.