What comes after git

18 points by ucirello

fzakaria

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

I have been trying out entire as well. Supposedly they are coming out with their replacement for pull requests soon, whatever that means.

sigmonsez

so i read the entire article and have nothing worth saying.

Why is this article lacking all detail and any specific problem.

erock

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

but why not patches over ssh?

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
  
  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
    
    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
- tuxes
  
  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.
- toastal
  
  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.