[cerved]

you can also setup a local remote which hardlinks the index so it doesn't occupy more space. Why? Idk. You don't want to share stash, rerere-cache, branches whatever.

Also handy if you're running an agent in a container on the local fs. Set up a local clone, contain the agent to that repo folder and have it hack away on that. Later, you step out of the container and do the syncing. You can't use worktrees in this situations.

Bare repos are also pretty cool. You can clone the git mailing list as a bare repo and search for threads there instead of setting up an mbox (same for the kernel obviously)

[fphilipe]

At that point you might as well use a worktree[1].

[1]: https://git-scm.com/docs/git-worktree

[sciolizer]

You can't use a worktree without write access to the shared object database. You can use worktrees, or you can containerize your agents, but you can't do both.

[cerved]

Doesn't work. You need to mount both the worktree and the repo which defeats the point

[sciolizer]

> hardlinks the index

I think you mean hardlinks the object database? The index (staging area) changes constantly. Not much point in hardlinking it.

Hardlinking the object database is the default behavior with you clone locally on linux. It's great for one-off clones such as CI/CD pipelines and agentic containers, but the benefit in terms of disk space saved is short-lived: as repos evolve independently, they replace their packfiles with new ones, and the new ones will not be hardlinked because they don't contain the same objects.

I like to keep bare repositories in dropbox, but I use `--no-hardlinks` when cloning, because before I did that, on one occasion, dropbox corrupted the bare repo, and my working repo was corrupted as a result.

[cyanydeez]

which harness has actual containment controls and not just suggestions?