I am excited for ersc because of the founders but I guess there wasn't a whole lot there if we are honest.
I just heard about entire.io on pragmatic engineer podcast. I wonder if it's something in same space: storing additional metadata like trajectories with the commits.
I was expecting a critique of git's design, and how e.g. Darcs or Pijul or something novel would fix aspects of it. I was disappointed by stuff about AI agents and git's storage.
I’m a big fan of jj and have completely switch my mental model of git away from the git client.
Having said that, this sounds more like they are trying to solve the issues around storing and serving repos in the cloud.
I also like the idea of breaking apart code forges and providing discrete components around it.
I desperately wish companies would get more creative around code contributions. The fork+pull request model feels so heavy.
My experimentation around this idea revolves around a patchbin service where you don’t even need a repo to collaborate on code. Patches over email is far too cumbersome but why not patches over ssh?
Ah, thank you. I actually thought there was a first-class interaction for "distributed PRs" but there have been a few of those projects and I thought maybe I mentally blurred them together
One will observe that the word "pr." does not appear anywhere on pico.sh nor in https://pico.sh/sitemap so that would lead a casual observer to think the service is abandoned. The domain does appear on https://github.com/picosh/patchbin but I would not have wanted to go clicking through all 31 repos to find it
I’ve still been playing with Darcs … & it came before Git—since I see fundamental flaws in Git too, tho I think incremental adoption is overrated. I’m still awaiting better Pijul tooling—for instance: standalone HTTP server, interactive rebase script.
From VCS I want instant isolated workspaces that have access to n projects which I can run builds across, and I want all that to be portable between machines, so that I can continue to work from anywhere, and so that I can easily use build farms.
As it stands, I have to manually manage directories/clones/worktrees/PRs, and I've not solved portability.
Since it's so frictionful, it's often significantly simpler to apply local workarounds than to develop and propose a patch upstream. Even if I propose a patch upstream and get it merged, I have to wait until it's released, which often doesn't align with my own timelines. Nix makes it ~easy to keep that patch around, which I'm often happy to do for a short while, but if it means I also have to maintain a frictionful workspace that includes my temporary fork, then suddenly that's a faff too.
The net result is that I don't contribute upstream patches that often. This is self-reinforcing. And I don't think this is just me. Across the FOSS world, that's a huge missed opportunity.
I hope ERSC is trying to solve some of that friction.
And you essentially get this architecture. It's all very proof of concept, and the documentation is non-existent, but it's really cool to see something like our internal system available for use.
It's truly magical to go to another host and not have to have pushed or anything to get the current state of the repo. I can't wait to set these up as a POC on my homelab.
Yada yada yada corporations, yada yada yada monorepo, yada yada big big yada.
What I'm interested in is whether the "what comes after git" can scale down to people. I get the impression that we're not the target audience here. And that's fine, too, software should have their target audience.
fzakaria | 14 hours ago
I am excited for ersc because of the founders but I guess there wasn't a whole lot there if we are honest.
I just heard about entire.io on pragmatic engineer podcast. I wonder if it's something in same space: storing additional metadata like trajectories with the commits.
samcat116 | 14 hours ago
I have been trying out entire as well. Supposedly they are coming out with their replacement for pull requests soon, whatever that means.
sigmonsez | 9 hours ago
so i read the entire article and have nothing worth saying.
Why is this article lacking all detail and any specific problem.
gspr | 4 hours ago
I was expecting a critique of git's design, and how e.g. Darcs or Pijul or something novel would fix aspects of it. I was disappointed by stuff about AI agents and git's storage.
erock | 8 hours ago
I’m a big fan of jj and have completely switch my mental model of git away from the git client.
Having said that, this sounds more like they are trying to solve the issues around storing and serving repos in the cloud.
I also like the idea of breaking apart code forges and providing discrete components around it.
I desperately wish companies would get more creative around code contributions. The fork+pull request model feels so heavy.
My experimentation around this idea revolves around a patchbin service where you don’t even need a repo to collaborate on code. Patches over email is far too cumbersome but why not patches over ssh?
mdaniel | 7 hours ago
https://pico.sh/pastes#:~:text=Upload%20code%20snippets%20using%20rsync%2C%20scp%2C%20and%20sftp
I thought they had a submission I could link to, but I guess the author only comments with links to it, not formal submissions
erock | 6 hours ago
Thanks for the ref, I was trying not to self-promote in this thread about jj. The git collab service is actually: https://pr.pico.sh
mdaniel | 6 hours ago
Ah, thank you. I actually thought there was a first-class interaction for "distributed PRs" but there have been a few of those projects and I thought maybe I mentally blurred them together
One will observe that the word "pr." does not appear anywhere on pico.sh nor in https://pico.sh/sitemap so that would lead a casual observer to think the service is abandoned. The domain does appear on https://github.com/picosh/patchbin but I would not have wanted to go clicking through all 31 repos to find it
toastal | 6 hours ago
I’ve still been playing with Darcs … & it came before Git—since I see fundamental flaws in Git too, tho I think incremental adoption is overrated. I’m still awaiting better Pijul tooling—for instance: standalone HTTP server, interactive rebase script.
tuxes | 8 hours ago
From VCS I want instant isolated workspaces that have access to n projects which I can run builds across, and I want all that to be portable between machines, so that I can continue to work from anywhere, and so that I can easily use build farms.
As it stands, I have to manually manage directories/clones/worktrees/PRs, and I've not solved portability.
Since it's so frictionful, it's often significantly simpler to apply local workarounds than to develop and propose a patch upstream. Even if I propose a patch upstream and get it merged, I have to wait until it's released, which often doesn't align with my own timelines. Nix makes it ~easy to keep that patch around, which I'm often happy to do for a short while, but if it means I also have to maintain a frictionful workspace that includes my temporary fork, then suddenly that's a faff too.
The net result is that I don't contribute upstream patches that often. This is self-reinforcing. And I don't think this is just me. Across the FOSS world, that's a huge missed opportunity.
I hope ERSC is trying to solve some of that friction.
ClashTheBunny | 4 hours ago
We just had an intern present their end-of-summer project, which is an instantiation of this idea:
https://github.com/jj-vcs/jj-commit-cloud-poc
Combine that with another intern's project:
https://github.com/jj-vcs/jj-vfs-poc
And you essentially get this architecture. It's all very proof of concept, and the documentation is non-existent, but it's really cool to see something like our internal system available for use.
It's truly magical to go to another host and not have to have pushed or anything to get the current state of the repo. I can't wait to set these up as a POC on my homelab.
maduggan | 3 hours ago
I mean I have learned nothing new. I am excited to see an actual product.
algernon | 3 hours ago
Yada yada yada corporations, yada yada yada monorepo, yada yada big big yada.
What I'm interested in is whether the "what comes after git" can scale down to people. I get the impression that we're not the target audience here. And that's fine, too, software should have their target audience.
spc476 | 38 minutes ago
There is no solo developer, there is only The Enterprise.