Activity

1. mnriem

   added

   bug-assess

   on Oct 21, 2026
2. github-actions commented on Oct 21, 2026

   

   github-actionsBot

   on Oct 21, 2026 – with GitHub Actions

   Contributor

   More actions

   Bug assessment — autocommit-default-ignored: Valid · severity medium

   ---

   Bug Assessment: git extension auto_commit.default ignored when event keys exist

   • Slug: autocommit-default-ignored
   • Created: 2026-10-21T14:11:10Z
   • Source: issue [Bug]: git extension: auto_commit.default: true has no effect with the shipped config template #5050
   • Verdict: valid
   • Severity: medium

   Report (summarized)

   Issue author @stefanwalther reports that the git extension config comment says auto_commit.default enables all commands unless overridden, but the shipped template also sets every event’s enabled: false. In the implementation, default fallback is only applied when an event section is absent, so setting only default: true does not enable listed events. The report includes a concrete reproduction using before_plan and shows that deleting the before_plan: block makes default apply.

   Symptom

   When users set auto_commit.default: true in the generated git config, auto-commit still does not run for standard events (for example before_plan) because those events are explicitly present and disabled in the template. Expected behavior per comment wording is that default enables all commands unless an event is explicitly overridden.

   Reproduction

   1. Install the git extension so .specify/extensions/git/git-config.yml is created from the shipped template.
   2. Set only auto_commit.default: true.
   3. Make a working-tree change and run bash .specify/extensions/git/scripts/bash/auto-commit.sh before_plan.
   4. Observe no commit.
   5. Remove the before_plan: section from git-config.yml and rerun step 3.
   6. Observe commit succeeds (default path applies).

   Suspected Code Paths

   • extensions/git/config-template.yml:28-36 — comment states default enables all commands, but template explicitly defines events with enabled: false, including before_plan.
   • extensions/git/scripts/bash/auto-commit.sh:163-168 — default is applied only when event key is missing (if ! grep ... ${EVENT_NAME}:), so explicit event sections suppress default.
   • extensions/git/scripts/python/auto_commit.py:108-111 — same fallback logic: use default only when event section does not exist.
   • extensions/git/scripts/powershell/auto-commit.ps1:160-164 — same fallback behavior in PowerShell implementation.
   • extensions/git/git-config.yml:28-36 — installed/default config mirrors the contradictory template behavior users actually encounter.

   Root Cause Hypothesis

   The defect is a configuration contract mismatch between documentation comments and parser semantics across all three script variants. The comments promise "default-on, then override per-command," but shipped config pre-populates per-event enabled: false, and parser logic intentionally treats any present event section as explicit override (so default is ignored). Confidence: high.

   Proposed Remediation

   Preferred: Align shipped config shape with current parser semantics and documented intent by removing per-event enabled keys from the default template (retain event message stanzas), so auto_commit.default genuinely controls all events unless users add explicit enabled overrides. This keeps parser logic stable across Bash/Python/PowerShell and makes behavior match the existing explanatory comment.

   Alternatives:

   • Reword comments/docs to state that default only applies to events not explicitly listed; lower implementation risk but preserves surprising UX and weakens "enable globally then override" ergonomics.
   • Change parser semantics so default true can override explicit enabled: false unless an additional explicit "override" marker exists; higher complexity and cross-language parity risk.

   Files likely to change:

   • extensions/git/config-template.yml
   • extensions/git/git-config.yml
   • extensions/git/README.md (example/behavior wording)
   • Potentially tests under tests/extensions/git/ that validate template/config behavior

   Tests to add or update:

   • Regression: with generated config containing messages but no per-event enabled, default: true should auto-commit for before_plan.
   • Regression: if a specific event has enabled: false, it must stay disabled even when default: true.
   • Cross-script parity test to ensure Bash/Python/PowerShell all honor the same precedence rules.

   Risks & Considerations

   • Behavioral change for users relying on current template defaults could alter first-run auto-commit behavior if not documented clearly.
   • Any parser-semantic change must remain consistent across Bash, Python, and PowerShell to avoid platform drift.
   • Silent no-op behavior is currently hard to diagnose; consider improved observability/logging if behavior remains conditional.

   Open Questions

   • [NEEDS CLARIFICATION: Should maintainers prefer changing template shape only, or changing parser semantics to make explicit enabled: false interact differently with default?]
   • [NEEDS CLARIFICATION: Should auto-commit scripts emit a debug/info message when skipped due to config disable to reduce user confusion?]

   Generated by 🐛 Assess Bug from Labeled Issue for #5050 · copilot · gpt53codex · 15.1 AIC · ⌖ 0.597 AIC · ⊞ 22.4K · ◷
3. github-actions

   added

   severity-medium

   on Oct 21, 2026
4. joshinitin2016883-sketch commented on Oct 21, 2026

   

   joshinitin2016883-sketch

   on Oct 21, 2026

   More actions

   I'd like to work on this. One note on the assessment's preferred fix: removing the per-event enabled: keys from the template isn't enough on its own, because all three scripts fall back to default only when the event's section is missing entirely (auto-commit.sh L163-169, auto_commit.py L108-112, auto-commit.ps1 L160-166). A section that keeps only its message: still blocks the default.

   Proposed fix: in all three scripts, fall back to default when the event has no enabled: key (an explicit enabled: false still wins), and drop the enabled: false lines from config-template.yml and git-config.yml so default: true works as the comment describes. I'd add regression tests for bash, Python and PowerShell, and can include Windows PowerShell 5.1 evidence. Does that work for you, or would you prefer the docs-only rewording?

   AI disclosure: posted on behalf of @joshinitin2016883-sketch. Drafted with Claude Code (model: Claude Opus 5.5), human-supervised; the analysis comes from the agent reading the scripts on main, and the contributor reviewed this comment before posting.