Checkpoint metadata lost after history rewrites (rebase, squash merge, force-push)

[arosenfeld2003]

Problem

When git history is rewritten (interactive rebase, squash merge, force-push), the Entire-Checkpoint trailer on user commits is lost. This breaks the link between code commits and their session metadata on entire/checkpoints/v1, effectively orphaning the checkpoint data.

This is inherent to how trailers work — they live inside the commit object, and any operation that rewrites commits produces new SHAs without the original trailers.

Proposed solution

Store a git tree hash in checkpoint metadata as a content-addressable anchor. A rebased commit has a different commit SHA but the same tree hash if the file content didn't change. A future entire repair command could scan the current branch for commits whose tree hash matches a checkpoint's stored tree hash and re-add the Entire-Checkpoint trailer.

Note: tree hash matching only works when file content is unchanged (clean rebase/cherry-pick); rewrites that modify content (conflict resolution, squash combining multiple commits) will need additional heuristics like timestamp proximity or file-set overlap.

Steps

1. Store commit_tree_hash in metadata — PR Add commit_tree_hash to checkpoint metadata #319
2. Implement entire repair command — scan branch history, match tree hashes, re-add trailers

Impact

Any workflow that rewrites history (common with squash merges, rebasing feature branches onto main) will silently lose checkpoint links. The entire session cleanup command already detects orphaned checkpoints but cannot fix them.

[Soph]

Thanks for opening this.

When git history is rewritten (interactive rebase, squash merge, force-push), the Entire-Checkpoint trailer on user commits is lost. This breaks the link between code commits and their session metadata on entire/checkpoints/v1, effectively orphaning the checkpoint data.

This is inherent to how trailers work — they live inside the commit object, and any operation that rewrites commits produces new SHAs without the original trailers.

Trailers are not living inside the commit object or are attached to SHAs they are just part of the commit message (so they change the SHA when added later). In general git operations like rebase are not removing the trailers. During local squash they can get lost if the user isn't manually moving them over (we have a fix / improvement in the works for this) but for example if you squash merge a PR on GitHub then the trailers are preserved and all are just kept (you end up having multiple on the commit message)

A rebased commit has a different commit SHA but the same tree hash if the file content didn't change.

Now this here is the issue. The tree hash is calculated across the whole tree of the repo so it's super unlikely that a rebase isn't changing that. Similar on a squash you keep the last commits tree hash but the ones before are also lost.