Rendered at 04:20:21 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
pkghost 34 minutes ago [-]
Having gone down the worktree rabbit hole for a month or so, I am giving up in favor of multiple checkouts to enable many agents to work across many repos.
Worktrees worked great for me when my agents' work was mostly contained to a single repo (they got me to finally hitting rate limits, not that that was a goal). As my homelab scales, agents increasingly work across multiple repos, and that's where (my approach to) worktrees broke down; agents were spawned in a repo worktree and so avoided stepping on the toes of other agents in the same repo without any special instruction, but as soon as they needed to touch another repo, they would default to working in that repo directly, without a worktree, and thus collide with other agents, and muddy a merge process that expected the main repo clone to be clean (which turns out to have been an unnecessary design quirk, but resolving it would still not stop agents from stepping on each other's toes in secondary repos).
After a detour through ZFS dataset clones and some mounting magic that made /srv/src/ appear to be a distinct hierarchy for each agent process, I am simplifying even further and giving each agent a bare directory (sth like /srv/dev/<slug>/) where they can check out any repos they want. The git remote (/srv/git/) becomes the only integration point.
Maybe I should just bite the bullet and move into containers, but performant as they are the ergonomics still bum me out.
zmmmmm 1 hours ago [-]
The real problem for parallel dev is ensuring parallel dev environments can seamlessly co-exist without treading on each other. As soon as one of them wants to open a port, talk to an external database or write to a shared location as part of testing you have them conflicting with each other.
Much of this is a legacy dev issue where there was never so much of an assumption that parallel ephemeral dev environments would be in play in the first place. But legacy dev is still most of dev.
irskep 3 hours ago [-]
I use git worktrees daily. I'm surprised by how hard it can be to explain them to people who have never used them. Lately I've settled on "like clones, but sharing a .git directory." The article tries to get this across by comparing them to branches, but I think clones are a more intuitive concept to compare against.
To solve some of the ergonomics issues (command verbosity, manual commands to copy over .env files and install dependencies), I wrote autowt, which is a lightweight but powerful worktree manager: https://steveasleep.com/autowt/
Once I dialed in the cli experience, I basically stopped typing 'git checkout <branch>' to change tasks, because it's easier to ignore working directory state when flipping between tasks.
rhyperior 2 hours ago [-]
I just ran into a situation where I had two Claude instances working in the same repo on two different, independent issues. I noticed the sessions were thrashing a bit on which branch they were on because each was taking control from the other session. That’s when it hit me why I need worktrees.
skew-aberration 50 minutes ago [-]
Working on an embedded device that requires building firmware images, etc, I've taken to using docker containers with a COW overlay. I have a vibe-coded tool which checks out the latest and does a clean compile, creating a base directory. Then I spawn a build container on top of that. Every build is warm, as they share ccache and page cache. Huge speed up for parallel builds and I never OOM. Every build also sees the same directory structure, simplifying instructions, etc for the agents.
hankbond 57 minutes ago [-]
Dang I read this as
> Parallel development without the headaches from using Git worktree
Read the whole thing just waiting for the complaints to start!
thunderbong 4 hours ago [-]
Fossil SCM, conventionally, has been thus way by default.
One struggle I've had when working with worktrees is not a problem with the worktrees themselves but instead how my Intellij manages project configurations. I can't for the life of me get it set up so my configuration can sit relative to multiple worktrees. There's probably a plugin which solves the issue, but at least in my experience the .idea config folder is rooted in its current directory and very difficult to migrate to another folder or worktree. I end up having to re-establish project linting rules, run configurations, what have you, for each new worktree and it becomes too much of a hassle for anything short-lived.
sa46 1 hours ago [-]
IntelliJ added worktree “support” but it’s really just a way to create a new project.
I suspect it’ll take a while before we see a shared configuration across worktrees because the .idea folder contains mutable state.
very rarely use more than 4–5 per project. Maybe I'm just avoiding wrapping my head around worktrees and actually trying them out.
Benefits: These clones act as semi-permanent directories:
- Helps with caching for heavy Docker usage (think of repeated parallel unit, e2e tests)
- I've color-coded my terminal tabs for each clone so I can instantly tell where I am at a glance (kinda like tab groups just with colors)
Maybe if for some reason I need double digits clones of a project I will be more forced to use git worktrees because then it will be annoying to remember in which directory a branch clone lives.
agrm 2 hours ago [-]
this is basically what worktrees do, though? except git 'knows' about all the associated branches, so you don't have to deal with pushing/pulling in order to merge xyz branch, etc.
The one real caveat to this is that if your application has particularly heavy cold starts it can be hard to actually run your worktrees. I usually end up swapping to a regular checkout as each worktree is due for hands-on attention.
lacunary 3 hours ago [-]
I'm curious what the constraint preventing you from optimizing the cold start time - can you share more?
kajika91 4 hours ago [-]
This is very interesting and could be very helpful for A/B testing or comparing outputs/speed between 2 branches.
I already know a place I want to use this.
on_the_train 1 hours ago [-]
There's a huge limitation with work trees that makes them borderline unusable: they can never be active on the same branch. Which includes that you can only ever have one on the master branch.
modeless 1 hours ago [-]
Yeah they aren't worth the trouble just because of this. Multiple checkouts are the way to go unless your repo is so huge that you can't afford the disk space. You can clone them from each other so you don't need to download the repo over and over and you can send branches back and forth locally if you really need to, though I never do.
I use it's config to copy in some non-repo config and then hooks to start an agent doing analysis.
pydry 3 hours ago [-]
I do the same thing just checking out the repo multiple times in different directories.
I'm not really sure what worktrees adds on top of that.
MaulingMonkey 3 hours ago [-]
Worktrees share more git state (remotes, blobs, etc.) and don't require hunting down the repository url to feed to git clone, or a network connection to use said url. While you could get the same benefit from cloning your local repository, you're then in the weird state where `origin` is a local non-bare repository.
If you're setting up long-lived checkouts that you reuse, it doesn't help much (except perhaps saving space or bandwidth) vs multiple clones and some once up-front reconfiguration. On the other hand, if you want something more temporary - and perhaps based on your current HEAD without having to hunt down a commit id to feed a subsequent git clone / git checkout command - worktrees save you some boilerplate (re)configuration.
recursivecaveat 3 hours ago [-]
It makes coordination easier. For eg if you want to fetch and pull master, you only have to do that once. If you want to rebase checkout A's branch on top of B's, you can just do that, you don't have to push between the two.
esafak 3 hours ago [-]
Less space.
kimseungyong 3 hours ago [-]
[flagged]
jmpeax 4 hours ago [-]
What a peculiar title. The title suggest parallel dev without using worktrees, but the article is about using worktrees.
michaelsmanley 4 hours ago [-]
I thought that as well and then realized I had inserted the word "of" before "using" where there's an implied "by."
Worktrees worked great for me when my agents' work was mostly contained to a single repo (they got me to finally hitting rate limits, not that that was a goal). As my homelab scales, agents increasingly work across multiple repos, and that's where (my approach to) worktrees broke down; agents were spawned in a repo worktree and so avoided stepping on the toes of other agents in the same repo without any special instruction, but as soon as they needed to touch another repo, they would default to working in that repo directly, without a worktree, and thus collide with other agents, and muddy a merge process that expected the main repo clone to be clean (which turns out to have been an unnecessary design quirk, but resolving it would still not stop agents from stepping on each other's toes in secondary repos).
After a detour through ZFS dataset clones and some mounting magic that made /srv/src/ appear to be a distinct hierarchy for each agent process, I am simplifying even further and giving each agent a bare directory (sth like /srv/dev/<slug>/) where they can check out any repos they want. The git remote (/srv/git/) becomes the only integration point.
Maybe I should just bite the bullet and move into containers, but performant as they are the ergonomics still bum me out.
Much of this is a legacy dev issue where there was never so much of an assumption that parallel ephemeral dev environments would be in play in the first place. But legacy dev is still most of dev.
To solve some of the ergonomics issues (command verbosity, manual commands to copy over .env files and install dependencies), I wrote autowt, which is a lightweight but powerful worktree manager: https://steveasleep.com/autowt/
Once I dialed in the cli experience, I basically stopped typing 'git checkout <branch>' to change tasks, because it's easier to ignore working directory state when flipping between tasks.
> Parallel development without the headaches from using Git worktree
Read the whole thing just waiting for the complaints to start!
https://fossil-scm.org/home/doc/trunk/www/gitusers.md
I suspect it’ll take a while before we see a shared configuration across worktrees because the .idea folder contains mutable state.
https://www.jetbrains.com/help/idea/use-git-worktrees.html
Benefits: These clones act as semi-permanent directories:
- Helps with caching for heavy Docker usage (think of repeated parallel unit, e2e tests)
- I've color-coded my terminal tabs for each clone so I can instantly tell where I am at a glance (kinda like tab groups just with colors)
Maybe if for some reason I need double digits clones of a project I will be more forced to use git worktrees because then it will be annoying to remember in which directory a branch clone lives.
git worktree list
git worktree remove
All you need
I already know a place I want to use this.
I use it's config to copy in some non-repo config and then hooks to start an agent doing analysis.
I'm not really sure what worktrees adds on top of that.
If you're setting up long-lived checkouts that you reuse, it doesn't help much (except perhaps saving space or bandwidth) vs multiple clones and some once up-front reconfiguration. On the other hand, if you want something more temporary - and perhaps based on your current HEAD without having to hunt down a commit id to feed a subsequent git clone / git checkout command - worktrees save you some boilerplate (re)configuration.