Hacker News Reader

Comment by MarkSweep | Hacker News Reader

> Multiple Git Checkouts

You don’t need to do a full clone to have multiple working copies of your repo checked out. You can use the git worktree command to create these working copies:

https://git-scm.com/docs/git-worktree

View on HN

What is the advantage of worktrees over multiple clones? Using multiple clones is trivial - there are no new git concepts to learn - and works perfectly with all build tools particularly ones that heavily use caching. What productivity improvements do worktrees bring?

Probably makes it a bit easier to propagate changes between copies

Yes, exactly. Git worktrees will for instance make it easier to merge changes between multiple checked out branches without pushing upstream.

For big repositories with long histories (like Qt), worktrees also save some disk space.

Moving work/commits from one local clone to another is something I do regularly - just using vanilla git push/fetch.

I’ll grant that saving disk space is a concern for many - not for me - the largest repo I use is 2-3 million LOC with about 10 or 15 years history and the 4-5GB per clone doesn’t bother me.

> just using vanilla git push/fetch

Right but that's quite a lot more faff than not having to do anything at all.

Significantly less disk usage is the main one for me. If you have a workflow where each task has a worktree, and you have 10-15 tasks in progress, and the repo is a decades old monorepo, then storing only one copy of the history is a big savings.

A task could be any small thing that requires its own checkout for some possibly stupid reason, like running the regression tester or temporarily running an old version of a binary out of your dev checkout over NFS if there was a bad deploy.

FWIW, local git clones use hard links for object files, so share a lot of their data.

https://www.git-scm.com/docs/git-clone#Documentation/git-clo...

Yeah, but if you work with a central repository, when using local git clones the clones are hanging off the local repository, not the central one.

Sure, you can change back origin to point to the central one again, but you still have to do a dance to sync branches among your local clones (and I’m not sure what happens to the hardlinks).

worktrees just naturally basically are “views” of the same local repository, which may hang off a central repository (or not).

Yes, that would be a different reason to prefer worktrees (that I mostly agree with). I was responding to the specific storage space claim.

I work with massive repositories, and creating new worktrees works in an instance, because it only creates hardlinks instead of copying files. Saves disk space, too.

Also, all branches stay in sync between worktrees. For example, I do git fetch on one worktree, and remote branches are up to date on all of them.

Branches are shared between worktrees. It's a significant benefit.

The only downside is that they don't work with submodules, if you are unfortunate enough to be using submodules.

I use them a bit at my work and the main reason is to reduce how much I’m fetching (which can take a couple of minutes). It’s also good for avoiding accidental inconsistencies between copies (Git will complain if you try to check out the same branch in MyProj and AltMyProj if they are both worktrees). You can checkout the same commit in two worktrees though so you can still do it in practice if really necessary.

I use worktrees, but some builds which uses git hash will fail in worktree checkouts, thinking that "it's not a git directory" (forgot the exact error, it's been a while); haven't found a solution to this

One way to get an error when retrieving a git hash is by building inside a Docker container. If you mount the root directory of a work tree, but not the “git-common-dir”, git will fail to give you the commit hash.

They mention git worktrees in the next paragraph.

Reply on news.ycombinator.com