Live data from Hacker News

Git at any scale

cursor.com

91–100 of 128 posts

Re: Git at any scale

#91
post #52

There's nothing Cursor can do that GitHub/Microsoft can't in 2026... And vice versa... after several years of Cursor vibecoding a GitHub clone while catching up with GitHub's new features. Git's performance it's not the issue; it's GitHub Actions, PRs, etc. The moment Cursors steals paid GitHub customers and gets the same workloads, they will start having similar issues! Stealing engineers who couldn't fix this at Gi…

I'd argue that for whatever other faults they have, Composer 2.5 is pretty competitive as an implement-planned-work model. It's several times faster than Sonnet 5, cheaper, and performance is comparable. Ears wide open for a model that does better for the same parameters. Pareto efficiency is important, but Anthropic doesn't seem to care about it. They desperately need a Haiku 5, IMO.

I use Claude with the Codex plugin as a critic (sometimes I switch and manually review with Claude). With the Superpowers skill (which I am trying to get rid of), it designs expensive models and implementations, uses cheaper ones for other, less important stuff, including Haiku, sometimes upgrading if it hits a roadblock, and then, finally, reviews with expensive ones. Why would I need Composer unless I'm a poor hobbyist? I care about value created, not about the affordable costs. So far, Claude and Codex have given me a huge ROI and are worth every penny. I don't even use an IDE, although I pay for Zed, or the terminal anymore - Claude and ChatGPT desktop apps give me everything and keep things simple. I just watched Theo yesterday [0], and I realized I'm not alone.

[0]: https://www.youtube.com/watch?v=dLhcLqoff6k

Re: Git at any scale

#92
Agents didn’t just make Git harder to host. They likely mandate a new layer between humans and code, and that layer now needs its own versioned artifacts.

A few scaling trends, all triggered by coding agents, make it unsustainable to keep stacking agents on the interfaces designed for human uses — Git, PRs, CI, review:

1. Time to produce a given feature dropped by orders of magnitude. Review, CI, and branch workflows were calibrated to human writing speed. The gates did not get faster.

2. Users will not consume 100x more features. They expect 100x more value from each interaction. The interesting artifact is no longer “the code that implements a feature.” It’s the mapping from intent to outcome.

3. Intermediate work exploded while durable output shrank. Agents leave scratch repos, traces, failed attempts, discarded implementations. The thing the user actually wanted got smaller and more valuable — closer to “satisfy this intent” than “ship this feature.” That is a lure to build much more complex software, and we are versioning the scrap heap with the same tool we use for the product.

4. The primary goal of software engineering till today is to share actions between users, so their intent are served through the same routines. Such software only satisfy commonality. It's now possible to build based on peculiarity. With that, a whole new space of personalization.

This looks like the history of machine tools: first powerful and imprecise, then more powerful and enormously precise. Software has to make the same jump — much more useful, and much more personalized.

I don’t know what the end state looks like. I doubt Git should remain the central mechanism.

Edit: Revised with help of AI.

Re: Git at any scale

#93
post #62
post #52

There's nothing Cursor can do that GitHub/Microsoft can't in 2026... And vice versa... after several years of Cursor vibecoding a GitHub clone while catching up with GitHub's new features. Git's performance it's not the issue; it's GitHub Actions, PRs, etc. The moment Cursors steals paid GitHub customers and gets the same workloads, they will start having similar issues! Stealing engineers who couldn't fix this at Gi…

Perhaps you didn't read the article, but the implementation they describe is interesting and perhaps easier implemented in a new project from scratch. It can't be any worse than current github, and since we've heard plenty of people express their dissatisfaction with github recently, this is actually a good direction for Cursor. A product people may want. We'll see.

Oh, I told my son to create an org yesterday with Cursor Origin, just in case in 10 years it becomes a thing, and he said: "Oops! Paid customers only!" A GitHub "alternative," really? Well, this is reminding me to cancel my Cursor subscription. I am paying for it but not using it because I don't need it as it offers me nothing. I won't even say that somebody already got my GitHub org name, so I'm sure there will be an aftermarket for org usernames and people who want to get 10-15-20x of their $20 investment. Cursor's shortsighted decision is definitely welcomed by parasites! They rushed out their MVP so badly that they created an identity fiasco!

Re: Git at any scale

#95
The problem is that Musk acquired Cursor and therefore Cursor has zero credibility.

I don't care about what they say because of who they sold out to

Re: Git at any scale

#96
post #88
post #62

Earlier quoted context omitted.

Perhaps you didn't read the article, but the implementation they describe is interesting and perhaps easier implemented in a new project from scratch. It can't be any worse than current github, and since we've heard plenty of people express their dissatisfaction with github recently, this is actually a good direction for Cursor. A product people may want. We'll see.

I am just too old, you know. I remember Bitbucket, GitLab, and the plethora of other GitHub killers. GitHub is an ecosystem, not a product. Cursor needs at least a decade to beat that! Maybe more!

Maybe what we need is actually fewer ecosystems, and more products.

Re: Git at any scale

#97
post #33

Earlier quoted context omitted.

Just like with climate change, the problems Elon creates don’t go away just because people are reminded of them. He still pushes his agenda, he still has lots of followers who believe his nonsense

[flagged]

To stay out of prison and having his companies federalized. I can't wait for municipal starlink.

Re: Git at any scale

#98

> The "fan-out" is synchronized with a classic consensus algorithm called 3PC (three-phase commit) so that a push is only accepted if a majority of the nodes acknowledge it. Doesn't 3PC require all nodes to agree, not just a majority?

I would think so - outside this sentence the author indicates they're talking about consensus across all members. IE - the interactive diagram and note about latency being bounded by the slowest replica

hmmm, I think they might be using a quorum-based 3PC variant. Reading https://github.blog/engineering/infrastructure/building-resi...> does make it seem like they only need a majority to commit instead of all nodes.

Ah, and then it looks like the losing nodes get marked unhealthy:

> In essence, every write operation goes through a voting protocol, and any replicas on the losing side of the vote are marked as unhealthy—unavailable for reads or writes—until they can be repaired. Repairs are automatic and quick. Because a majority agreed either to accept or to roll back the update, there are still at least two replicas available to continue accepting both reads and writes while the unhealthy replica is repaired.

But not sure how unhealthy nodes are discovered. Maybe the coordinator marks them, and if the coordinator crashes it allows stale reads and detects invalid writes?

Re: Git at any scale

#99
post #33

Earlier quoted context omitted.

Just like with climate change, the problems Elon creates don’t go away just because people are reminded of them. He still pushes his agenda, he still has lots of followers who believe his nonsense

[flagged]

[flagged]

Re: Git at any scale

#100
post #4

> What about consensus? Elections? Which server is the primary for a given repository? It also doesn't matter! There's no state and no consensus here. Any server can be the primary. All updates to the write-ahead log are synchronized with an atomic compare-and-swap (CAS) operation on S3, so it's always safe for any instance of a repository to receive a push. Again reminded of what an amaizing piece of engineering S3…

It is amazing and keeps adding new features that make it better. The CAS stuff is absolutely wonderful and only a recent addition!
Post reply on HN