That is, because the metadata is shared between worktrees. So you when you modify a branch in one worktree, it isn't modified per worktree, but in the whole repo. So what you need to do is to duplicate the branch metadata. That's what git clone does. You essentially have these cases:

    shared worktree, shared branch/index data, shared object storage  -> single repo, single worktree
    separate worktree, shared branch/index data, shared object storage  -> repo, with worktrees
    separate worktree, separate branch/index data, shared object storage  -> git clone
    separate worktree, separate branch/index data, separate object storage  -> git clone --no-hardlinks

You can checkout a commit twice though. What I don't get is what checking out a branch twice gets you. As soon as you add a single commit, these branches will be different, so why not just create another branch? Branches in git are cheap.

▲ matheusmoreira 3 days ago | parent [-]

Makes sense to me, thank you. It's just something I tried to do once. I didn't think very hard about it so it felt like an arbitrary limitation.

What I tried to do was have two copies of the same branch checked out to a different directory: one pristine, another with uncommitted changes. The idea was to run make on both directories, profile the results and then decide whether to commit or discard the changes. Now I see the solution is to just make another branch.

	▲	1718627440 3 days ago \| parent [-]
		Yeah in this case I wouldn't probably even bother with branches and only checkout the commit. Another way to solve this problem are of course VPATH-builds.