alt Hacker NewsIn git you can have only one worktree per branch. For example, if you have a worktree on main you cannot have another one on main.
I personally find this annoying. I usually like to keep one pristine and always current working copy of main (and develop if applicable) around for search and other analysis tasks[1]. Worktrees would be ideal and efficient but due to the mentioned restriction I have to either waste space for a separate clone or do some ugly workarounds to keep the worktree on the branch while not keeping it on the branch.
jujutsu workspace are much nicer in that regard.
[1] I know there are tons of ways search and analyze in git but over the years I found a pristine working copy to be the most versatile solution.
Replies
> In git you can have only one worktree per branch. For example, if you have a worktree on main you cannot have another one on main.
You can detach the worktree from the repo, and checkout multiple branches at the same time to different locations. Not sure if this also allows checking out the same branch to multiple locations at the same time. You can also have a swallow clone, so you don't have to waste space for the full repos history. So at the end you still have to waste space for each worktree, but this isn't something jujutsu can avoid either, or can it?
That sounds like a nice improvement, just like many other aspects of jj!
Tools should adapt to us and not the other way around, but if you are stuck with git, there's a slightly different workflow that supports your use case: detached head. Whenever I check out branches that I don't intend on committing to directly, I checkout e.g. origin/main. This can be checked out in many worktrees. I actually find it more ergonomic and did this before using worktrees: there are no extra steps in keeping a local main pointer up to date.
OK nice to know. Don't find this limiting for my flow but will keep in mind if I decide to give JJ a try.
You probably know this, but for others that don't: local git clones will share storage space with hardlinks for the objects in .git. The wasted space wouldn't be a doubling, it would be the work tree twice plus the (small) non-hardlinked bits under .git. No idea how LFS interacts with this, but it can be worth knowing about this mechanism.
Also, if you end up relying on it for space reasons, worth knowing that cloning from a file:// url switches the hardlink mechanism off so you end up with a full duplicate again.