I noticed that when update_linked_gitdir chooses to update .git/worktrees/<id>/gitdir, the path it writes is relative, at least under some circumstances. This contradicts the gitrepository-layout man page, which says:
worktrees/<id>/gitdir:: A text file containing the absolute path back to the .git file that points to here. IIUC, this behavior defeats one of the three safeguards that is supposed to prevent "git worktree prune" from pruning information for worktrees that still exist. A simple script to reproduce: #!/bin/bash set -e -x rm -rf repo worktree2 git init repo cd repo touch foo git add foo git commit -m 'dummy commit' git worktree add ../worktree2 -b branch2 cat .git/worktrees/worktree2/gitdir touch -d '2 days ago' .git/worktrees/worktree2/gitdir (cd ../worktree2 && git status) cat .git/worktrees/worktree2/gitdir Trying this on master as of earlier today (ff4ea60), I get: [...] /PATH/REDACTED/worktree2/.git [...] .git Matt -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
