> The way objects and branch references was set up by git-new-workdir was completely safe for git-gc not to lose other workdir's data. The simplest example is

> The way objects and branch references was set up by git-new-workdir was completely safe for git-gc not to lose other workdir's data. The simplest example is when the only live reference to a commit is a detached HEAD. Because HEAD is duplicated per workdir, other workdirs do not know about HEAD, and if it doesn't refer to an actual ref, it's subject to garbage collection. This isn't much of a risk if there's constant ongoing work (because then the GC grace period and the reflog will typically save you), but it can be a problem if you're dealing with a branch that sees only intermittent work. Even without that, it's pretty easy to destroy graph ancestry (which is not actual repository content, but still fairly important metadata). Example: set -e git init g cd g echo 1 >foo git add foo git commit -m test cd .. sh git-new-workdir g g2 cd g2 git checkout -b foo echo 2 >foo git commit -a -m foo git branch -d master cd ../g echo 3 >foo git commit -a -m master git log --graph --all The above script will disconnect one branch from the rest of the repository. The underlying problem is that there are some important invariants that Git needs to maintain to ensure repository integrity in the presence of mutable history, and if part of the information is held in a place that it does not know about, it may not be able to maintain those invariants. There's a reason why `git worktree` goes to a lot more effort to prevent such scenarios by registering worktrees with the repo and why `git worktree lock` is still needed.