The problem with multiple checkouts via worktrees is that you end up with different build directories. For small projects, that’s fine, but for something big like LLVM I want a release build and a debug + asan build and that adds up to almost 80 GiB. Doing the build also takes a lot of time, so I’d rather switch branches and do an incremental build.

What I really want is something like a FUSE FS that uses git worktrees to give me different views of the same git repo easily, but also gives me a CoW (or, better, dedup’d) view of the associated build directory and lets the build tool see a view of the source where it only sees changes between branches and some common ancestor.

i like to think of a project as more than just code, it has notes, references, sample data, blueprints and what not. so i start by creating a directory for the project and have all the code (worktrees) reside in one corner of this directory:

project/
|- worktrees/
|  |- main/
|  |- feature/
|  `- bugfix/
|- notes/
|  |- timeline.txt
|  `- builds.txt
|- reference/
|  |- prior_art.txt
|  `- similar_project/
`- test_data/

so i suppose it starts with:

mkdir -p project/worktrees && cd project/worktrees && git clone xyz main

What I do is I clone the project to a branch named after the default branch, ie main, inside a directory named after a project. That way, when I checkout a worktree 1 directory above it is on the same level as the main branch

I usually have one worktree per project. E.g. projectA/linux, projectB/linux, etc.

I’ve been initializing repositories from a bare clone for a few years now. The trick is to clone the git directory under, well, .git.

git clone --bare $remote $out/.git
cd $out
git worktree add main
git worktree add fix-something
# …

With this strategy, you also get a simple git integration with any file manager, i.e. directories correspond to branches and worktrees are not nested.

Unfortunately, Git currently writes absolute path to $out/.git in worktree. That can be fixed by manually editing worktree/.git to refer to gitdir: ../.git.

You could steal the suggested layout from Subversion:

• trunk/projectA and branches/projectA/{feature…,bug…} or
• projectA/trunk and projectA/branches/{feature…,bug….}

Replace trunk with “master” or “main” as needed.

I use $project for the main and then $project–$branch in the same parent directory. Also, I’ve noticed that git worktrees don’t work exactly the same as a regular repo. For instance you can’t switch a worktree to an already checked out branch, for some reason.

This very much sounds like a Node problem. I don’t do Node, but for things I do do where I might need per-project dependencies installed somewhere, I guess Python, I would use virtualenvs outside of the git repositories. (I’m not yet yet using multiple git worktrees with any of my Python projects.)