Matt McCutchen <m...@mattmccutchen.net> writes: > 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:
Duy, is it safe to say that the fix has already been cooking in 'next' as nd/do-not-move-worktree-manually topic, we are about to solve this by merging down to 'master', _and_ it is very much appreciated when reporting bugs people check if a presumed fix is already cooking in 'next', try it to verify if it really fixes their problem, and send in a "OK fix is good" / "No that does not fix my case"? > > 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
