Skip to content

fix: bound stalled git commands with actionable diagnostics - #86

Open
mvanhorn wants to merge 1 commit into
kunchenguid:mainfrom
mvanhorn:fix/64-git-command-timeouts
Open

fix: bound stalled git commands with actionable diagnostics#86
mvanhorn wants to merge 1 commit into
kunchenguid:mainfrom
mvanhorn:fix/64-git-command-timeouts

Conversation

@mvanhorn

Copy link
Copy Markdown

Testing

  • A normal git command that completes before the deadline returns the same trimmed output and ordinary nonzero-exit diagnostics as today.
  • A git command run with an already-expired or deliberately short context terminates and returns a timeout-specific error rather than a generic exit error or an indefinite wait.
  • The timeout diagnostic identifies the git subcommand and working directory and includes actionable stale-lock guidance for checkout/reset-style failures.
  • IsHeadMergedIntoRef retains its special exit-code-1 meaning for an unmerged head while using the same bounded command execution path for hangs and other failures.

What Changed

Centralize subprocess construction in internal/git/git.go around exec.CommandContext and apply a conservative default deadline to every git command, including the merge-ancestor path that currently bypasses runGit; this protects fetch, worktree creation, checkout/reset/clean, and the repository-discovery commands without changing every caller. Preserve existing exit-code handling for commands that finish normally, but distinguish deadline expiry and return an error that names the stalled git operation and working directory, with concise hints for stale .git/index.lock, credentials, and network checks. Keep the timeout policy local to the git adapter rather than introducing a broad pool API or a helper used only by tests; the issue's immediate correctness requirement is a bounded failure, while the centralized duration remains a single production setting that can be exposed through configuration separately if maintainers want that additional surface.

Why

treehouse get and treehouse return ultimately launch git subprocesses through internal/git, but those commands have no deadline. A stale repository lock, blocked credential helper, or stalled network operation can therefore leave the CLI indefinitely at its setup banner. The maintainer confirmed the gap and invited a PR, and the issue has no assignee, competing PR, or closed-unmerged prior attempt.

Fixes #64

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

treehouse get can hang indefinitely with no timeout or diagnostic if git operations stall

1 participant