[qingyun-wu]

Problem

In a submodule or worktree checkout, .git is a file (a gitdir: pointer) rather than a directory. catchup-after-startup.sh tested [ -d "$REPO/.git" ] in two places, so on such a checkout:

• The repo auto-detect probe rejected an otherwise-valid checkout (even with CLAUDE.md + skills/ present and git fully functional).
• The "Recent commits" section short-circuited to (no .git at $REPO) — even though git -C "$REPO" log works perfectly.

Once that gate is opened, a second, flaky bug surfaces in the same section: git log … | head -25 under set -o pipefail intermittently prints (git failed). When the window holds >25 commits, head closes the pipe after 25 lines, git receives SIGPIPE (exit 141), and pipefail propagates it as a pipeline failure.

Fix

1. -d → -e at both the auto-detect probe and the commits-section gate. -e accepts a .git that is a file or a directory, so normal, submodule, and worktree checkouts all pass.
2. Decouple head from git's pipe. Capture git log output inside the if (so git's real exit status is the only failure signal), then trim with head on a plain string where a SIGPIPE can't affect git.

Verification

On a submodule checkout (public sutando pinned inside a private super-repo, .git = gitdir: ../.git/modules/sutando):

• Before: ## Recent commits → (no .git at $REPO).
• After the -e fix: section entered git path but flaked — (git failed) on ~1 in 3 runs.
• After both fixes: 8/8 runs populate the commits list reliably.
• Auto-detect also now finds the repo when SUTANDO_REPO_DIR is unset and cwd is the submodule.

bash -n clean. No set -e in the script, so the decoupled printf … | head assignment is safe. Scope is limited to the two .git checks and the one pipeline; no behavior change for plain-directory checkouts.

Follow-up to #1056.

[qingyun-wu]

Q: Does -d → -e have side effects? Does it break the normal (non-submodule) case?

No regression for normal checkouts — -e is a strict superset of -d here. -d path = "exists and is a directory"; -e path = "exists (any type)". Everything -d accepted, -e still accepts; it only adds the file-form .git.

Scenario	.git is	-d (old)	-e (new)	Change?
Normal checkout	directory	✅ pass	✅ pass	none
Submodule / worktree	file (gitdir pointer)	❌ fail (the bug)	✅ pass	the fix
No git repo	absent	❌ fail	❌ fail	none

In a normal checkout .git is a directory, so -d and -e return identical results — byte-for-byte same behavior. The change only accepts one new shape (the file-form .git), which is exactly the submodule/worktree case being fixed.

Theoretical false positive? If .git existed but were garbage (e.g. an empty file that isn't a valid gitdir pointer), -e would pass the gate where -d wouldn't — but both call sites degrade gracefully:

• Commits section: a subsequent git -C "$REPO" log failure falls to (git failed), no crash.
• Auto-detect probe (line 25): the .git test is ANDed with -f CLAUDE.md and -d skills, so a stray .git file alone can't trigger a false repo detection.

-e also matches git's own notion of "is this a repo" better than -d — git treats both the directory and the gitdir-pointer file as valid repos.

Verified across all three cases:

=== Case 1: normal checkout — .git is a DIRECTORY ===
  -d : PASS
  -e : PASS
  => identical (both PASS). No behavior change for normal repos.

=== Case 2: submodule/worktree — .git is a FILE (gitdir pointer) ===
  -d : FAIL  <- the bug (valid repo rejected)
  -e : PASS  <- the fix

=== Case 3: no .git at all ===
  -d : (correctly) FAIL
  -e : (correctly) FAIL
  => both reject. No false positive.

Net: safe relaxation, zero behavior change for standard non-submodule checkouts.

[sonichi]

LGTM — two correct + well-traced fixes.

Submodule/worktree .git detection: -d → -e is the right invariant. Per git help repository-layout: in a submodule or git worktree add-style secondary checkout, the .git entry is a file containing a gitdir: <path> line, not a directory. Your guard now matches both shapes — and rejects nothing legitimate, since -e still requires the entry to exist.

De-flake commits section: classic git log | head -25 SIGPIPE-via-pipefail trap. head closes the read end after 25 lines, kernel sends SIGPIPE to git log, git exits 141, set -o pipefail propagates that as the pipeline status, and the if branch falsely reports "(git failed)" even when git did exactly the right thing. The capture-then-trim split is the cleanest fix — keeps real git failures distinguishable from "I asked for the first 25 of many" — and matches how scripts elsewhere in the repo handle the same pattern.

Tests + CLA green; per the no-bot-merge-authority rule leaving the merge press to Chi.

[sonichi]

LGTM — both fixes are correct and well-scoped.

1. -e not -d for .git — exactly right for submodule/worktree checkouts where .git is a gitdir-pointer file. Applied in both the REPO probe (line ~24) and the section-8 commits check (line ~258). Symmetric, no regression for normal checkouts.

2. SIGPIPE-pipefail de-flake — capture-then-head pattern correctly isolates git's real exit status from the head-closes-pipe race. The inline comment explains the failure mode clearly. Bonus that the empty-window vs git-failed distinction now lives in the explicit if block rather than the __FAIL__ sentinel hack.

Nothing in my recent PRs (#1072 /startup, #1074 /task-orphan-check, #1075 revert) touches this file, so no merge conflict risk. Ship.