Hacker News Reader

Comment by noosphr | Hacker News Reader

Luckily we already have a distributed version control system that can take over github: https://fossil-scm.org/home/doc/trunk/www/index.wiki

I suppose people can use git too if they ever figure out how to send emails from a dedicated client.

View on HN

There are plenty of alternatives for git hosting. The last thing which needs to be migrated before we get an exodus off this vibe coded monstrosity is reputation (i.e. github stars) which are inherently sticky.

Git doesn't even need to be "hosted" anywhere. That's the point of it being distributed. What needs to be hosted somewhere are all the barnacles (like issue tracking, code reviewing, CI, and so on) that have grown out around git, that people and businesses have become dependent on.

Which is why they cleverly moved the central story of a software change from the commit to the PR. Commits migrate automatically with the repo. But migrating PR descriptions and comments takes engineering effort.

Rhetorically, why can't folks add the feature of PRs to Git? Git is fundamentally just a graph manipulation engine and data structure. It would just be another object type, in a layer which sits above the normal commit graph. Obviously there is no "just make X" in software, but this feels reasonably achievable, and would have tremendous benefit for the cost.

https://git-scm.com/docs/git-request-pull

Where would you put comments then? Sure, there’s always mailing lists, but even so, someone still has to host Mailman.

I do think GitHub has positively contributed to the software industry and open source. It’s been enshittified for sure, but it has had a golden era.

LFS files sorta do need to be hosted. At least, it exists because full clones are untenable for many projects.

It doesn't have to be. But without a hosted "source of truth", it's kinda hard to actually distribute it, and have a way to accept pull/merge requests/patches.

In regards to issue tracking there are alternatives. Epiq is a git-native (vendor agnostic) issue tracker you self-host: https://ljtn.github.io/epiq/

Github stars are a metric of what?

If I build something that satisfies me and say 100 users (who all star me) does that really say anything. Are those 100 stars even "real" any more?

All the old problems of the web are new again, and still remain unsolved.

github stars are a metric of investability.

some investors use stars (and star growth velocity) to determine which projects they invest or don't invest in. (not saying it's good or bad - just saying it's a real thing.)

I don't think GitHub stars are what makes GitHub sticky. Having a single UI / account and being able to jump between work projects, private projects and random open source projects where I want to open a quick issue or submit a PR is much more sticky.

The reason why GitHub is sticky was exactly this. It’s easy to fork, make a change, and submit a PR to another project. It’s the same interface for your code vs another person’s. It’s a simple, consistent interface to submit an issue.

You can argue that the lack of diversity in infrastructure is bad, and I wouldn’t disagree. I think we should have more projects to explore better ways of working. But, the tradeoff is that when you have a centralized system, like GitHub, you also have less friction. The learning curve is small when everything uses the same tools.

I think as we see more AI participation in code, github stars are going to matter less.

My main reason for using Github is stars (bookmarking)

> Luckily we already have a distributed version control system that can take over github

Surprised that this wasn't just a link to Git. The biggest benefit of Git over predecessors was that it enabled decentralization. Github re-centralized the common case for the sake of convenience.

Yes but on Earth every project needs a canonical main branch. Most also need a way to manage and review changes to that branch that all project members have direct access to.

Gitea (and its popular fork, Forgejo) are very lightweight. You can easily stand up an instance on a cheap VPS.

Agreed. Just moved some of my projects to codefloe.com (Forgejo) this weekend. FYI - it provides a lot more than a link to git.

It's on the project to decide which is canonical and export a read only accessible version. Change review only requires a communication medium (the patches are mostly plain text) and that can be done in a lot of way. As for merging those changes, it's an organizational issue.

If it’s on the project to determine their requirements, why are you doing it?

Github and other providers before proved that git itself is just a small part of managing code, there's a lot more needed for a full workflow, and it's meaningful for it all to be tightly coupled.

> "Crypto had attracted grifters from the beginning, even though its most respected figures were more interested in changing the world. As Silicon Valley investors piled in after them, they wanted to fund companies that would become essential to the crypto economy, allowing them to make vast amounts of money. Entrepreneur after entrepreneur discovered that the best way to turn a profit in a decentralized economy was to figure out ways to centralize parts of it again." (Henry Farrell, Underground Empire)

The biggest benefits of Git over predecessors were branching, 3-way merge, and history rewrites (in particular, rebase and squash). As much as Git fans wanted decentralization to be a major selling point, decentralization has never been a major selling point.

Not exactly decentralization but distribution was the main selling point.

In comparison to SVN and other non-DVCs git did not need to continuously talk to the central server for history, "branch" creations, unlocking/locking files before changes, etc.

Linus wanted a DVCS, but they wanted centralization and licenses were expensive, so he decided to launch the git initiative where he provided scaffolding and the rest came from contributions.

It was a selling point. Maybe even intended selling point. But it absolutely isn't the main selling point. Never was, never will. The big thing, the reason people ever started talking about Git outside Linux dev team, has always been branches. It's branches, not distribution, that made every SVN user in the world abandon it in exchange for Git. Saying distribution has been more important than branching is like saying automobiles replaced horses because of smell. Which, admittedly, was a big problem with horses, but come on.

It seems our experiences are different.

Back then, when working with SVN, we had sites in various countries, with under provisioned VPNs between them. Loading up a single file history could take 15 minutes. I am not joking. Every single operation took ages, so really, any DVCS would have won in that situation, regardless of its approach to branches.

If the SVN server would sit in the same building then I guess the branching would have been the main selling point, but it was not the main selling point for us in that situation.

I think you understate what a big deal the decentralization was when Git came out. Back in the early 2000s, getting internet while out of the office was hard. 3G was in its infancy and expensive so you were at the mercy of finding a WiFi hotspot. Git's predecessors, such as SVN, were unusable without an internet connection to the server. Git (and Mercurial) allowed doing version control without an internet connection for the first time, which is a massive benefit for some types of development or doing work on the road. This aspect of Git definitely became less important as always-on internet connections became ubiquitous, but it's still super helpful sometimes. I can't imagine going back.

I think you understate what a big deal branching was when Git came out. Back in the early 2000s, branching was hard. Git's predecessors, such as SVN, didn't have branching at all until much later, and even then the implementation was riddled with problems and quite often the repo entered state where branches cannot merge back to main (which was called trunk back then).

No matter how beneficial the ability to work offline was, branching was still far more important. It's a completely different order of magnitude. Git without offline capabilities would still be a massive success. Git without branching would not.

I like Fossil, but there are good reasons to use git too.

There are many git hosting options, including some for self hosting. its a lot easier to switch to a different version control host than to a different version control system.

We had Launchpad before Github (IIRC).

Reply on news.ycombinator.com