> it took until 2015 to even support something as basic as multiple checkouts of the same repository via `git worktree`
This feature was supported many years before that via a separate script.
This feature was supported many years before that via a separate script.
That’s not the point of GP post. In fossil for example, one can have multiple checkouts of a single repository (on a single computer by the same person) without fear this will lead to data loss. I don’t think this was suggested as a backup strategy, just a workflow feature.
At the same time I can't claim it is guaranteed to be "no data loss" because I didn't review all the code. If you are strongly concerned about data loss you would probably use backups, _regardless_ if you use git, fossil etc.
Agree strongly.
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 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.