I have been trying to debug why Claude (and Cursor) often skips running “git pre-commit hooks”, despite being in the Claude.md. I have to remind it every prompt, and even then it fails to run them. They only show up in CI, failing immediately (without running the test-suite). Now, this is also happening to the Dragonboat team and I know it’s not a me-problem.
One of the things that I changed during this debugging was to make each agent clone their own repo — our repos are quite small — and I’ve kept up with this practice, as there is no real advantage for me in keeping a centralized local repo. In fact, this way I am sure they don’t change the centralized database, potentially interfering with each other. In fact, I had some issues where agents would reuse branches, mixing different PRs together.
But worktrees have some significant limitations. Not least of which is that their dependence on hardcoded fully-qualified paths written into configuration files not only makes worktrees non-portable, but also makes them DOA for any kind of containerized development environment. The worktree.useRelativePaths option helps here, but as of this writing it’s still relatively brand-new (Git v2.48 released Q1 2025), and not available in the version of git you probably have installed on your host machine or any of your container images. On top of that, VSCode’s support for relative worktrees with devcontainers is experimental, totally undocumented, and (as of this writing) unreliable at best.
— Avdi Grimm in You probably don’t need git worktrees
I wasn’t aware of all of those disadvantages, but it is so easy and fast to clone a new version. And even if you want to work offline, you can just clone from another local repo, like I did in 2007 when there was no wifi on campus.
Now if you have a multi-gigabyte repo, you might think twice about skipping worktrees. But then you have bigger problems to worry about.