There are a bunch of posts on the internet about using git worktree command. As far as I can tell,
most of them are primarily about using worktrees as a replacement of, or a supplement to git
branches. Instead of switching branches, you just change directories. This is also how I originally
had useed worktrees, but that didn't stick, and I abandoned them. But recently worktrees grew
on me, though my new use-case is unlike branching.
And cherry-pick commits done on different work trees without syncing them first. Or rebase or mergeworkk done on one work tree with others. Or check commit logs or diff them.
The different worktrees share the same .git state. The article has an example where the author uses one tree for writing code and one for fuzzing it. If they used multiple clones they’d have to push from the writing directory and pull from the fuzzing directory to get new commits to fuzz but with worktrees this state synchronization between different git directories happens automatically.
The benefit is that you have everything collected in one place. You can jump between any of your local branches, and there’s no confusion about which state the branches are in.
If you have multiple clones, then there’s the risk that you’ve forgotten to sync main in all your different clones.
Then there’s also the problem that all the generated binaries will be out of sync. You still have 5 copies of each binary.
I guess I don’t understand this feature. Is there an advantage in using worktrees rather than multiple clones? Is it mainly for IDE integration?
I use worktrees and I wondered the same question, so far here’s what I like:
git worktrees listcan show all the worktrees, you have for this same repo (not crazy value, I know)git fetchapplies to all your worktreesgit stash / applycan work across worktrees, so I can stash in one and apply it to anotherYou’re limited to a specific branch per worktree and many don’t like that but I typically work from a detached HEAD anyways.
And cherry-pick commits done on different work trees without syncing them first. Or rebase or mergeworkk done on one work tree with others. Or check commit logs or diff them.
The different worktrees share the same .git state. The article has an example where the author uses one tree for writing code and one for fuzzing it. If they used multiple clones they’d have to push from the writing directory and pull from the fuzzing directory to get new commits to fuzz but with worktrees this state synchronization between different git directories happens automatically.
It’s just clones but with shortcuts, I don’t see the point of m
did you just shortened “them” to “m”?
It’s just them with shortcuts, they didn’t see the point of m
😏
Nah, I just think the ‘m’ should be scrapped from the alphabet
You don’t see the point of making use of shortcuts?
For navigating trough messy systems or unusual places, yes. But you know where you keep your repos. To me, this is bloat.
Why would you do this to yourself?
The benefit is that you have everything collected in one place. You can jump between any of your local branches, and there’s no confusion about which state the branches are in.
If you have multiple clones, then there’s the risk that you’ve forgotten to sync main in all your different clones.
Then there’s also the problem that all the generated binaries will be out of sync. You still have 5 copies of each binary.