Who would have thought that git worktree is the technology of the year 2026?
Yeah, when you had multiple agents working on the same machine, branch isolation was no longer sufficient.<p>A repository folder can only be on one branch at a time.<p>A worktree is basically equivalent to a cp -R + git branch, which allows this new workflow to occur.<p>I loved this particular historical insight as to why `git worktree` was added in 2015:<p>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.<p>Running git stash and switching branches alters timestamps on thousands of files.<p>This forces `make` to perform a full re-compile, which can take up to an hour on large kernels.
I still don't understand how people use git worktrees with Docker. You need a full database and etc. For me it's simpler to have multiple checkouts.
And the team behind opencode is working on an alternative <a href="https://github.com/anomalyco/rift" rel="nofollow">https://github.com/anomalyco/rift</a>
this looks similar to something I built <a href="https://github.com/ThatXliner/git-worm" rel="nofollow">https://github.com/ThatXliner/git-worm</a>
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.
Gitbutler still a better option than any worktree like variant
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
How small are people’s projects if they find worktrees useful? I use them for hobby stuff, but $DAYJOB is a different story because of testing
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
I have moved from my own awkward scripts to lazyworktree TUI and I loved it
I can barely keep up with one single thread and branch, go figure.
best tool yet!
It is nice.<p>But!<p>The reason these tools exist is not because of non-professional developers, but quite the opposite.<p>A lot more professionals are now working on more projects simultaneously- something that was not practical just a year ago.<p>Though, while this is nice, considering that all of the action is happening on the same device, I am worried this is going to increase supply chain risks. Before, a developer would work on clearly designated projects for practical reasons. Now, the same developer can work across many projects that are quite different - for example, the marketing site and the backend - and because of an obscure and unimportant component on the marketing site, there can be an impact on backend systems.<p>I wrote more about this here: <a href="https://chatbotkit.com/reflections/everyone-is-a-vip-now" rel="nofollow">https://chatbotkit.com/reflections/everyone-is-a-vip-now</a>
If I'm interpreting this correctly, GitHub will use their existing actions infrastructure to run versions of the code in isolated worktrees. I think this could be a very beneficial process.<p>What I've done on my end is created a project where I have a remote Linux workstation. I can create multiple worktrees for each repo in that workstation, and then my agent can push PRs to GitHub and use the actions infrastructure to see if the integration tests that it writes for itself are successful without needing to run those integration tests on the local environment. It's expensive in terms of runner hours, but the automaticity of it is incredible.
Looks good, but after pricing change I have already used 26% this month with very light usage.<p>Last month I used Copilot heavily, much much more than I usually do, but did not manage to use more than 58%.
That looks pretty close in shape to the early Ace project Maggie Appleton demonstrated last month.<p>Edit: This short talk – <a href="https://maggieappleton.com/zero-alignment" rel="nofollow">https://maggieappleton.com/zero-alignment</a>
I was thinking of the Codex app.<p>Particularly the left sidebar and conversation view look near identically structured.
I rather like Ace better because the key problem right now is teams <i>not</i> working together and shipping the wrong things. When AI can generate the code, then it feels like product should be bringing the functional vocabulary and grammar while the engineering team provides the technical grammar to build the right thing.<p>This app is just another "let me talk to product, copy their convo, go off and build this in isolation with an agent" which I think is directionally wrong.<p>The "rooms" or "streams" should be multi-player instead of product looking at it at the end saying "no, go fix that" and dev copies text from one source and pastes into another.
It's weird. I still remember 2008, when GitHub's claim to fame was that it was "the easiest (and prettiest) way to participate in the collaborative development of software."<p>Now they want to end that collaboration, and turn it into automation. Many C-suite executives right now are smiling bigly. Meanwhile, we're leading the exodus. Turns out, we <i>still</i> want the easiest and prettiest way to participate in the collaborative development of software, and GitHub ain't it!
As a side note, has anyone else noticed that GitHub have leaked what looks like a sequential customer number on their Billing - Usage page?<p>Go here and you’ll be redirected with a query string including a customer parameter. That looks like trouble.<p><a href="https://github.com/settings/billing/usage" rel="nofollow">https://github.com/settings/billing/usage</a>
That information is public https://api.github.com/users/<username>
I just see a 404, though I’m not signed in.
Oh nice! I guess they're back to features after finishing tackling their availability issues [1].<p>[1]: <a href="https://github.blog/news-insights/company-news/an-update-on-github-availability/" rel="nofollow">https://github.blog/news-insights/company-news/an-update-on-...</a>
Unrelated to the feature itself, but remember a few months ago when someone posted Github's beta feature for stacked PRs, and a ton of people slammed them for releasing a seemingly vibe-coded site? To quote Mitchell Hashimoto, "One of the most requested GitHub features in years and the website looks like it was designed by someone 9 years into a 2 year community college program."[1]<p>When opening the posted link, my first thought was "imagine if the stacked PRs site had the same amount of effort put into it as the Github Copilot App site". They clearly have other preview features on this site already, so maybe I'm just confused on why stacked PRs got some b-grade announcement site. The obvious answer is "copilot", but I'm still curious.<p>[1] <a href="https://x.com/mitchellh/status/2043788123008868600" rel="nofollow">https://x.com/mitchellh/status/2043788123008868600</a>
I know it has the same functionality, but it also looks like the Codex app which looks like Cursor Agents! Are they sharing some VS Code primitive here?
How is this different than the separate Agents app shipping with VS Code?<p>Other than fewer features.
More evidence that GitHub is chasing features over stability of their platform.
looks like google antigravity 2.0, a standalone app instead of a vscode plugin.
Let me guess: some ElectronJS crap instead of a native UI?
It's kind of interesting that everyone is going for the desktop app format now.<p>These desktop agentic coding tools are a large UX step up from the CLIs, but I still think the future is going to be remote development as the coding agents start running for hours at a time. Building a desktop app seems short-sighted as it would just lock them out of the remote option completely.
You can get to it wherever you want. Copilot CLI is pretty great: <a href="https://github.com/features/copilot/cli" rel="nofollow">https://github.com/features/copilot/cli</a><p>There's support in VS Code and Jetbrains IDEs. You can access your agent sessions on the web.<p>(I work at GitHub, but not on Copilot)
Doesn't lock you out at all. Codex already had a companion app for mobile so you can send prompts to your desktop app while you go about your business. The infrastructure is there. Server might move from your desktop to cloud at some point but not much changes. Still needs somewhere to run.
I think their goal is to lock you into their ecosystem instead of using your IDE
But now is now, and what you are talking about is a future that may or may not exist.
The desktop app can become a client for their remote cloud agent solution (yuck).
Codex App can spawn/control Codex agents running in the cloud.
So, it's not open source?
copilot had such a lead when this whole ai coding thing started. what happened?
Too slow on the move to agents<p>Plus the whole naming confused people<p>I still talk to co-workers who think claude code == agents and copilot is just VS autocomplete
Microslop bureaucracy + leadership politics.
Blog post: <a href="https://github.blog/news-insights/product-news/github-copilot-app-the-agent-native-desktop-experience/" rel="nofollow">https://github.blog/news-insights/product-news/github-copilo...</a>
they should have spent this engineering time on stability.
"This page is slowing down firefox"
Here is the kind of crap they are building instead of focusing on stabilizing their core business features.<p>And after they will accuse the growth and all to be responsible for their stability issues...
[dead]
[flagged]