←back to thread

Jujutsu worktrees are convenient (2024)

(shaddy.dev)
128 points nvader | 1 comments | 03 Dec 25 23:26 UTC | HN request time: 0.216s | source
Show context
rafaelmn ◴[08 Dec 25 10:15 UTC] No.46190591[source]▶
So how is this different from git worktrees exactly ?
replies(2): >>46190753 #>>46191208 #
weinzierl ◴[08 Dec 25 11:49 UTC] No.46191208[source]▶
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.

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(6): >>46191261 #>>46191697 #>>46191865 #>>46192204 #>>46194289 #>>46197961 #
1. regularfry ◴[08 Dec 25 13:50 UTC] No.46192204[source]▶
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.