This is pretty cool and solves one of the problems I've had whilst playing around with things like Cursor: that it breaks my flow having to wait 5-10 minutes for it to generate code/documentation, I'd really like to use that time to focus on my main work whilst it does some grunt work. Worktrees looks like it might provide a solution to this
Functionality-wise, it seems very similar to just "git cloning" another copy of the repo in a different directory (you can even use the "main" local repo as its source, and "pull" from that), which at least to me seems more intuitive to reason about and doesn't require me to learn any new commands or worry about any limitations like the issues with submodules or not being able to have the same branch checked out twice (clones don't mind).
It's a nice idea, and I'm going to try to remember them as an option for future scenarios where they might be useful, but I think the reason they never caught on generally is just that they're not bringing anything to the table that can't already be easily accomplished by other means.
git worktree is just so much easier to work with if you want to work on multiple versions or branches of some code.
It allows having multiple IDE instances open, all fully functional and indexed, and handing over commits from one worktree to another without having to fetch constantly in between.
Trying to emulate this with multiple clones feels like trying to do OOP in C -- sure one can do it, but it's pointless hassle compared to a fleshed-out solution that works right out of the box.
Not to mention it's so much faster and more efficient than git clone.
Yeah, I didn't see the use for them until I got further into it over just cloning. Your worktree "folders" share the same git history and stuff. So you can stash in one and apply in the other. If you do a fetch in one, it fetches for all of them.
Whether it's worth it for others to learn these just for those things is hard to say. I picked it up simply because I was bored and wanted to pick up a new "thing".
Yeah, I think their saving grace is that they really aren't that hard to use. I don't use them often enough to remember the commands by heart, but it doesn't take me long to figure it out anew each time. Typically not as long as cloning the repo anew, at least.
it seems very similar to just “git cloning”
Worktrees take less space, and the fetch/pull only has to be done once. It's a nice feature but restricted to workflows where you work on a lot of features at the same time.
yeah, I think these are the main hurdles for me:
When you create a new worktree, it is created from whatever is comitted, so gitignored or uncomitted files are not copied.
So if you have .env files, you have to copy them over manually. And for dependencies, like for example node_modules, you would have to run npm install again in the new worktree.
Mainly .env files, as they are handcrafted. And:
A few projects I work on are multi-root (using VS Code terminology) and that's already complex enough. Adding worktree directories means adding a level to that, which I'm not bought in. And I don't want a separate workspace for each branch I work on, that just shifts the complexity from git to the IDE / editor.
I've stopped using bare env files on the repo, I'll create an env file that populates values from a secrets manager and check this file info git. Or throw the env file info a parent dir because they're probably user specific anyway.
Having an env file that needs to exist but isn't checked into source control creates "works on my machine" issues as well, just load them from the environment and provide a programmatic way of setting the environment (or stop pretending they're part of the project and use direnv/Mise to setup the env)
So I can’t help with the IDE issue, but my answer to files that need to be available ln every worktree would be symlinks. So your .env in your repo would really be a symlink to the real .env that lives somewhere else in your system. Sure, you need to create a new symlink when creating a new worktree, but otherwise editing the symlinked file updates every worktree.
And of course, for those worktrees that do need their own versions of some files (e.g. maybe you keep an old release branch of the project in a worktree) you’d use a real file and not a symlink
Then we have the "it works on my machine" issue. I'm vehemently against symlinks pointing out of the code repository because of that.
If they're untracked files anyway, that's unavoidable.
If they're ignored files, setting them up locally won't end up in the repo. If you put a symlink into the repo, fixing that for your setup will register as a change within git, which can cause annoyance and even problems down the line.
Yeah, the untracked files not being copied is also a big reason why I'll typically just switch to a different branch instead.
I mainly use worktrees when it's useful that untracked files are not copied, like when I need to check out a completely different state of the project, where cached files would need to be invalidated anyways, for example.
I use them all the time, but that's just because of Yocto and the need to keep at least the 3 major LTS builds hot in the event something breaks.
Unfortunately some developer tools fail to work correctly in separate worktrees. I used them for a while but had to give them up. For example, Maven's release plugin cannot reliably create tags / branches if you're in a separate worktree.
Worktrees are great, unless you have submodules...
I use submodules for worktrees. You usually just have to run git submodule update --remote within any new worktree dir.
Worktrees are great, and a good reason (if you needed any more) to avoid submodules like the plague. Worktrees don't work with submodules.
Which didadvantages of submodules did you find?
I see tree:
git submodule update --init --recursive every time you checkout a commit. There's an option to do it automatically but it's super buggy and will break your .git directory.The list goes on... Some of them depend on exactly what you're using them for.
The slightly frustrating thing is that there isn't a great answer for what to use instead. Git subtree has its own problems. Language-specific package managers do too. There aren't any good languages agnostic package managers I know of.
I'm really hoping Jujutsu will come up with a better solution because it is possible. But it's hard, and they are constrained by Git compatibility so I won't hold my breath.
The slightly frustrating thing is that there isn't a great answer for what to use instead.
Packaging libraries with Guix is a great solution.
Also, strict backwards compatibility in APIs is totally worth it. It makes developing larger systems so much easier.
Yeah I've seen Nix and Guix suggested but they seem like a huge extra layer of complexity.
Also, strict backwards compatibility in APIs is totally worth it. It makes developing larger systems so much easier.
Usually not for first party code. It adds extra maintenance burden for little benefit.
For example suppose you want to add an extra parameter to a function. In a monorepos you just do that and fix all the compilation errors. Send one PR through CI. Job done.
With submodules... You have to add a new function so it's backwards compatible. Deal with a default value for the old call, maybe add a deprecation warning. Oh and you need to version your library now. Then good luck finding all the places that function is called and updating them...
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities !webdev@programming.dev
