Most active commenters
  • SCdF(3)

←back to thread

848 points thefilmore | 15 comments | | HN request time: 0.001s | source | bottom
Show context
bandrami ◴[] No.43969975[source]
Pretty cool that Linus Torvalds invented a completely distributed version control system and 20 years later we all use it to store our code in a single place.
replies(29): >>43969999 #>>43970002 #>>43970008 #>>43970018 #>>43970019 #>>43970028 #>>43970031 #>>43970032 #>>43970036 #>>43970037 #>>43970142 #>>43970154 #>>43970198 #>>43970282 #>>43970314 #>>43970343 #>>43970418 #>>43970419 #>>43970431 #>>43970434 #>>43970451 #>>43970472 #>>43970541 #>>43970904 #>>43971268 #>>43971299 #>>43971387 #>>43971586 #>>43988717 #
SCdF ◴[] No.43970018[source]
I get what you're saying, but tbf hosting on github doesn't (yet!) box you out of just moving back to that system. It's still just git. It's still distributed, in the sense that if github goes down you could still generate patches and email them around, and then push back to github when it's back.

Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git)

replies(9): >>43970039 #>>43970120 #>>43970143 #>>43970151 #>>43970180 #>>43970299 #>>43970301 #>>43970480 #>>43970514 #
1. littlestymaar ◴[] No.43970039[source]
> Everything surrounding code: issues, CICD, etc, is obviously another story

That's what Github is though, it's not about the code itself it's about all your project management being on Github, and once you move it, moving out isn't realistic.

replies(6): >>43970041 #>>43970050 #>>43970059 #>>43970073 #>>43970450 #>>43970597 #
2. xboxnolifes ◴[] No.43970041[source]
Sure, but then we are no longer talking about git.
3. enos_feedler ◴[] No.43970050[source]
And how are we suppose to solve this problem? By creating distributed versions of every possible component of every piece of software? Seems unrealistic. I think we should be grateful that the core underlying protocol for the most important data has the distributed properties we want. It's a lot more than we can say vs. lots of other platforms out there.
replies(3): >>43970087 #>>43970202 #>>43971124 #
4. SCdF ◴[] No.43970059[source]
Right, but distributed git As Torvalds Intended™ doesn't solve those problems, so it's not related.

For the actual event we are commenting on, they have disabled all features other than code hosting and PRs.

replies(1): >>43970118 #
5. tigroferoce ◴[] No.43970073[source]
GitHub is about the community. There are others alternatives, more in line with what Mozilla claim to be their view (I'm thinking to GitLab, for instance), but nothing gives you visibility like GitHub.

Sad to see that Mozilla is becoming less and less what they promised to be once Google funding are depleting.

6. groestl ◴[] No.43970087[source]
> And how are we suppose to solve this problem? By creating distributed versions of every possible component of every piece of software? Seems unrealistic.

That's how we started out.

replies(1): >>43970252 #
7. Flimm ◴[] No.43970118[source]
It's impossible to disable PRs on GitHub, sadly. See https://github.com/dear-github/dear-github/issues/84
replies(1): >>43970714 #
8. hnlmorg ◴[] No.43970202[source]
As a GitHub user myself, I don’t disagree with your point. However I’d like to say that this isn’t quiet as different a problem to solve as it might first appear:

The issue tracking can be a branch and then you just need a compatible UI. In fact some git front ends do exactly this.

CI/CD does already exist in git via githooks. And you’re already better off using make/just/yarn/whatever for your scripts and rely as little on YAML as possible. It’s just a pity that githooks require users to set up each time so many people simply don’t bother.

9. baq ◴[] No.43970252{3}[source]
Maybe that's the reason everything tends to get centralized.
replies(1): >>43971381 #
10. arp242 ◴[] No.43970450[source]
GitHub has a fairly extensive API without too many limits AFAIK. You can definitely migrate all your data to $something_else if you want to.
11. LtWorf ◴[] No.43970597[source]
I managed to move to codeberg all my projects. There's everything except the secret deals with pypi to directly publish from github. Which is massively insecure anyway.
12. SCdF ◴[] No.43970714{3}[source]
Interestingly mozilla has effectively done this here, by using a GitHub action that automatically closes any PR with a message explaining that PRs are not to be used.

It's very silly they have to do this, but at least they can I suppose.

13. int_19h ◴[] No.43971124[source]
By storing issues etc in the repo itself. A git repo is just a generic object graph, after all, and objects don't necessarily describe files.

There are several such solutions already. The problem is that neither of them is popular enough to become a de facto standard. And, of course, centralized git providers like GitHub have a vested interest in keeping in this way, so they are unlikely to support any such solution even if it does become popular enough.

replies(1): >>43978369 #
14. groestl ◴[] No.43971381{4}[source]
It's an emergent phenomenon, it requires less energy expenditure overall. It's also the way of the Dodo.
15. enos_feedler ◴[] No.43978369{3}[source]
Wouldn’t it make economic sense for a git host to emerge that just did things this way and collect big pay for it? Gits been around forever and you’re idea sounds simple enough that a market of people would probably choose it on principle. There must be something more fundamental at play here.