fix(explain): find checkpoints merged into non-default target branches

[entire]

Trail: https://entire.io/gh/entireio/cli/trails/834

Fixes #931.

Summary

Merging a feature branch into a target branch dropped every session reference — checkpoint links and agent labels — from the target branch whenever the merge produced a merge commit and the target was not the repository's default branch. entire checkpoint list and entire checkpoint explain showed nothing for the merged work on that branch.

Root cause

getBranchCheckpoints and getAssociatedCommits scan history for Entire-Checkpoint trailers. On every branch that is not the repository default, they used a first-parent-only walk. Checkpoints brought in by a merge live on the merge commit's second parent, which a first-parent walk never visits — so the references vanished from the target branch.

A prior fix restored a full DAG walk, but only for the repository default branch (isOnDefault). Every other merge target stayed broken:

• a non-default target such as a release branch, or
• main itself, when git resolves the default branch elsewhere (e.g. origin/HEAD still points at master).

True fast-forward merges were already fine — the moved commits and their trailers become the target's linear (first-parent) history — which is why the symptom tracked "merge commit into a non-default target" rather than literally fast-forward.

Fix

Replace the first-parent walk on non-default branches with walkBranchOwnCommits: a DAG walk that follows every parent not reachable from the default branch, pruning (never descending into) commits shared with the default branch.

• Discovers checkpoints merged in via second parents (the fast forward merge lost all session references in target branch #931 fix).
• Still excludes the default branch's own history at the merge base — the exact property that motivated first-parent traversal — so "main merged into a feature branch" continues to exclude main's checkpoints, and the walk never explodes into main's full history.
• Bounded by the existing commitScanLimit; zero new cost on write/commit/push paths.

One adjacent read-path gap closed alongside it

• Deep-history leak in the reachable-from-default set. computeReachableFromMain marked only the most recent MaxCommitTraversalDepth (1000) commits of main's first-parent chain. A branch that merged main in long ago — with main since advanced past that bound — left the merged-in former-main-tip outside the set, so the walk descended into main's older history and surfaced main's checkpoints on the branch (the leak invariant, in reverse). The scan stays bounded (mainSpineScanLimit, ~60ms regardless of main length — an unbounded scan was multiple seconds on a repo with tens of thousands of commits and runs on every read); when it stops before main's root it falls back to a commit-date frontier — any commit at or before the oldest scanned main commit is treated as main's history. This is the same commit-date boundary git's own rev-list uses for main..HEAD: it keeps the deep-history leak closed (a former main tip merged in beyond the window is older than the frontier, so still pruned) while erring toward exclusion (past the bound it may hide a branch-unique commit older than the frontier rather than risk a leak). First-parent-only semantics are preserved, so merged-in feature commits are still shown, and the scan runs once per command.

Out of scope: the ephemeral (shadow-branch) counterpart

The same "first-parent misses a merge's second parent" shape exists in the temporary / in-progress (shadow-branch) read path (isShadowBranchReachable). Making it merge-aware trades one harm for another — a full-DAG walk leaks a default-branch session's in-progress checkpoints onto a branch that merged the default branch in, while pruning shared-with-main hides the active session on a brand-new branch (checkout -b then start coding, before the first commit). The two are the same topological case and irreducible without persisting the session's origin branch, a feature-sized write-path change. This PR therefore leaves the shadow path at its pre-existing first-parent-only behavior (isShadowBranchReachable is byte-identical to main) and tracks the fix as follow-up #1730. #931 itself is a committed-checkpoint read-path bug.

Testing

go test ./cmd/entire/cli/... ./cmd/entire/cli/strategy/... green; gofmt -s and golangci-lint (0 issues) clean; affected tests also pass under -race.

Traversal scoping is locked down in both directions — merged-in discovery and default-branch exclusion — and every case below is mutation-verified: removing the reachable-from-default prune fails every exclusion assertion; reverting to a first-parent-only walk fails every discovery assertion; restoring the depth limit fails the deep-history leak test.

• TestGetBranchCheckpoints_NonDefaultTargetFindsMergedCheckpoints — the merged checkpoint is found on a non-default target, and a default-only checkpoint does not leak. The target is anchored at the default branch's tip so that default-only checkpoint is a genuine first-parent ancestor (previously it branched from the base commit, which made the "must not leak" assertion vacuous — it passed even with the prune removed).
• TestGetBranchCheckpoints_MainMergedIntoFeatureExcludesMainCheckpoint — merging the default branch INTO a feature branch does not surface the default branch's checkpoints (they arrive on the merge's second parent).
• TestGetBranchCheckpoints_OctopusMergeIntoNonDefaultTarget — an octopus merge (three feature parents) surfaces every merged checkpoint; default-branch checkpoints stay excluded.
• TestGetBranchCheckpoints_NestedMergeIntoNonDefaultTarget — a transitively merged sub-feature checkpoint (sub-feature → feature A → release) is discovered.
• TestGetBranchCheckpoints_DeepHistoryDoesNotLeakMainCheckpoint — with main advanced past the scan bound, an old main checkpoint merged in via a former-main-tip does not leak onto the branch (the commit-date frontier fail-safe prunes it). Fails without the fail-safe.
• TestComputeReachableFromMain_ScanIsBounded — the main first-parent scan visits at most mainSpineScanLimit commits regardless of main length (no O(main) read-path blowup). Fails with an unbounded scan.
• TestGetBranchCheckpoints_ComputesReachabilityOncePerCall — the scan runs once per getBranchCheckpoints call, not once per checkpoint.

Live before/after — same repo, non-default target release, feature merged via --no-ff

Verified end-to-end via the deterministic vogon hook-replay agent (real session hooks → shadow branch → condensed checkpoint on entire/checkpoints/v1), running a pre-fix binary and the fixed binary against the same repo.

Committed checkpoint (baseline pre-fix → fixed):

>>> entire checkpoint list        (pre-fix)          (fixed)
  branch       release            release            release
  checkpoints  0                  1  ● b7d5fa68…  "create a markdown file …"

Invariant re-checked live: on a feature branch with the default branch merged in (--no-ff), both the branch-point and the merged-in default-branch checkpoints stay excluded — the fixed and pre-fix binaries agree, confirming no leakage was introduced. The shadow (in-progress) path is unchanged from main, so the fresh-branch "checkout -b then start coding" session still shows exactly as before.

Edge matrix (live, isolated scratch repos)

Scenario	Result
Non-default target, --no-ff merge commit (the bug)	fixed — checkpoint visible
Non-default target, true --ff-only	still works
Default branch (main), --no-ff and divergent merge	still works (unchanged)
Multiple sessions on feature → ff-merge into main	all 3 visible
Target branch has its own checkpoint + merged-in feature	both visible
ff-merge performed from a linked worktree	visible (list + explain)
Octopus merge (3+ parents) into non-default target	all merged checkpoints visible
Nested merge (sub-feature → feature → release)	transitive checkpoint visible
Deep history: main advanced >1000 commits past an old merge-main-in	main's old checkpoints excluded (no leak)
Invariant: main merged INTO a feature branch	main's checkpoints still excluded

[Copilot]

Pull request overview

Fixes checkpoint discovery on non-default target branches when work is merged via a merge commit (so checkpoint trailers live on non-first-parent ancestry). This restores entire checkpoint list / entire checkpoint explain visibility for merged work on branches like release.

Changes:

• Replace non-default-branch first-parent traversal with a branch-scoped DAG walk (walkBranchOwnCommits) that follows non-default history including merge second parents while pruning the default branch’s spine.
• Update getAssociatedCommits and getBranchCheckpoints to use the new walk on non-default branches.
• Add/adjust tests covering non-default merge-target behavior and updated associated-commit expectations.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
cmd/entire/cli/explain.go	Introduces walkBranchOwnCommits and uses it to find checkpoint trailers on non-default branches through merge second parents.
cmd/entire/cli/explain_test.go	Updates expectations for associated commits and adds a regression test for non-default merge targets.

Comments suppressed due to low confidence (1)

cmd/entire/cli/explain.go:1404

• getAssociatedCommits now uses walkBranchOwnCommits, which does not guarantee commit order (it’s a BFS over parents). The returned slice is used to pick the author from commits[0] and is also displayed to users, so non-deterministic / non-recency ordering can produce incorrect author attribution and confusing output. Sort the collected commits by committer time (descending) before returning so both code paths are stable.

		err = walkBranchOwnCommits(ctx, repo, head.Hash(), reachableFromMain, commitScanLimit, func(c *object.Commit) error {
			cpID, found := trailers.ParseCheckpoint(c.Message)
			if found && cpID.String() == targetID {
				collectCommit(c)
			}
			return nil
		})