Yeah, when you had multiple agents working on the same machine, branch isolation was no longer sufficient.
A repository folder can only be on one branch at a time.
A worktree is basically equivalent to a cp -R + git branch, which allows this new workflow to occur.
I loved this particular historical insight as to why `git worktree` was added in 2015:
Before worktrees, kernel devs faced a major inconvenience when switching contexts, e.g., stopping feature work to fix an urgent bug on a release branch.
Running git stash and switching branches alters timestamps on thousands of files.
This forces `make` to perform a full re-compile, which can take up to an hour on large kernels.
Sadly worktrees do some stuff with the git folder that's made one development environment we inherited incompatible. Something about the .git folder not being a fully real .git folder maybe
Hah, I have a prototype of the same idea on my backburner! Excited to see this, though I don't understand some of their design choices. Will need to check out more closely.
I don't understand what docker problem would be solved by multiple git directories but not by multiple work trees?
Regardless of whether the former solves it, I was going to suggest you could use compose or whatever in your 'human' tree, and then tell the AI to use equivalent docker commands without using compose, so it gets anonymous/its own named containers, but you keep the convenience.
I use Conductor's spotlight (and a Pi extension I derived from it) but it's not perfect. Once a migration executes, I'm pretty much bound to it but at least once, I have just backed up the database before switching and then restored that.
I use a skill that basically boils down to 'keep track of ongoing work in a json file, create a new numbered clone for each separate thread of work, delete when done'. Worktrees are too opaque and not entirely isolated for my liking.
I've toyed around with worktrees but haven't found them very useful beyond that. I generally find it much easier to carefully prompt an agent so $TASK1 does not interfere with $TASK2
I tried them a while back and they were more annoying than anything. The only real use-case I have for them is stashing long-running changes that are not ready to be committed... but really probably should be anyways.
I set up multiple work trees in one vscode workspace last year and wrote in the agents.md how to merge branches - but I spend about a third of the time helping agents integrate and merge. I remember wishing the tooling would catch up
I used to create multiple local worktrees and mount the sub directories using Docker. This approach had significant limitations because many paths in the agent and .git files were hard-coded.
i have some fun experiments i'm doing with full virtualization middle ware of all sys calls for agents tools/shell commands/io, still far from daily driver, but allows me to do a very rich overlay / virtual file system tom foolery in place
“Before the Freedom of Information Act, I used to say at meetings, 'The illegal we do immediately; the unconstitutional takes a little longer.' But since the Freedom of Information Act, I'm afraid to say things like that.”
Great idea, to include learning into the regular work.
Can you explain how the lessons are generated?
It looks like there are no pre-generated lessons, they are created on the fly by the AI. Wouldn't it be possible to write a skill or similar that does the same with your existing coding agent?
After agent defined a general direction and send the proposed course via MCP, we search the internet to generate the structure of the course (what to include, what requirements are necessary etc.), then we give it access to a number of tools that create interactive materials in the course, to make learning more engaging.
We consulted behavioural scientists, and decided that the effortful activity of learning has to be separated from effortless-ish activity of AI-assisted coding, to make lessons more engaging. We also can control UI/UX much better than if lessons were delivered via CLI.
Very cool! Why was and the entire networking stack straight forward, but not HTTP (and TCP)? Could you take inspiration form other projects for things like DNS?
Up to TCP most protocols are very straight forward, atleast getting them to work semi reliable. But then TCP explodes in complexity with all the state management and possible paths a connection can take.
HTTP is mostly annoying because of all the text parsing :D
Yeah...HTTP/1 is one of those weird cases where the older protocol is considerably more difficult to implement correctly than the newer ""more complex"" standard. This is especially true if you want your server to work with they myriad of questionably compliant clients out in the world.
HTTP/3 might have been easier, and using QUIC+HTTP/3 in your hobby OS is a fun flex :)
I don’t think that http/3 is easier to implement than http/1.1 especially since h3 is stateful where http/1.1 is not. Especially not when everything should be working correctly and securely because the spec does not always tell about these things. Oh and multiplexing is quite a hard thing to do especially when you are also dealing with a state machine and each of your clients can be malicious.
I can't speak to http/3 (I haven't tried to impl it), but I can say that a bare-bones http/2 is very easy to implement because it doesn't try to pretend to be prose.
reply