fn foreign_leftover_detail(repo: &Path, path: &Path) -> Option<String>Expand description
Why the directory at path is not this repo’s leftover, when its
.git entry says so - None when it is ours to delete.
A link naming a git dir that still exists is the evidence the guard has
always accepted: when that git dir is this repo’s git COMMON dir - the
one git rev-parse --git-common-dir answers, so a project checked out
as a linked worktree or a submodule matches its own too - the directory
is this repo’s, record or no record. A leftover from an older forge
therefore still clears.
A link whose git dir is GONE cannot prove ownership: the repo may have
been moved, but a moved or deleted FOREIGN worktree parked under our
root produces the same shape, and so does a live worktree of ours whose
registration was pruned. The same is true of no .git at all (a write
recreated the path after the walk). There the evidence is a removal
this repo ADMITTED, recorded by remove_owned_worktree in the git
common dir before git ran: it travels with the repo (worktree prune
does not touch it) and exists only for a removal this repo started and
never finished.
A .git DIRECTORY is a checkout of its own - a worktree’s link is
always a file - and a .git that cannot be read as a link is refused
as well, so refusing is the safe direction wherever the evidence is not
ours. The link is READ, never resolved: a deregistration has already
removed the worktree admin dir it names.