71–80 of 481 posts
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.
To be fair, Git itself is a bit of a pain, and GitHub's main achievement is/was to make it somewhat bearable.
Earlier quoted context omitted.
If GitHub went down, how much would it impact the open source world? Sure, there would be local copies everywhere, but for a distribution version control system, it's pretty centralized at GitHub
If GitHub went down, the code would be fine (just announce a new official URL), but the main thing that would be lost is issues and pull requests. Maybe Git should add official support for issues and pull requests in its metadata to be fully decentralized.
Earlier quoted context omitted.
Plenty of people use Codeberg and Gitlab. And it's still distributed - I don't need to lock files and ask coworkers if I can work on them. Maybe if Git had native support for PRs and issues this wouldn't have happened. (And yes I'm aware of git send-email etc.)
In Codeberg, how does one even search for files containing a given string? Probably the #1 thing I do on GitHub is searching for files in a project containing a given string.
Earlier quoted context omitted.
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 dist…
> if github goes down you could still generate patches and email them around, and then push back to github when it's back. You could, but generally people can’t. They learn a set of narrow workflows and never explore beyond. GitHub use translates into GitLab use, but not into general git use workout a central repository. > Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a stor…
Correct me if I'm wrong, IIRC the previous "master" branch is `mozilla-central`. Now it has "main" and "autoland", what are they? Which one is the equivalent of mozilla-central before?
The "new" git default branch name is 'main' and 'autoland' existed before next to 'mozilla-central' and is the one where commits usually appear first.
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.
And: Even though source of truth is centralized for many projects in GitHub, git still benefits from being distributed: It's the basis for "forks" on VithUb and for the way people develop. Ja jung the clone locally and committing locally and preparing the change set for review. In the CVS/SVN days one had to commit to the ce teal branch way sooner and more direct.
Earlier quoted context omitted.
Plenty of people use Codeberg and Gitlab. And it's still distributed - I don't need to lock files and ask coworkers if I can work on them. Maybe if Git had native support for PRs and issues this wouldn't have happened. (And yes I'm aware of git send-email etc.)
In Codeberg, how does one even search for files containing a given string? Probably the #1 thing I do on GitHub is searching for files in a project containing a given string.
Earlier quoted context omitted.
> 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.
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.
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.
Earlier quoted context omitted.
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 dist…
> if github goes down you could still generate patches and email them around, and then push back to github when it's back. You could, but generally people can’t. They learn a set of narrow workflows and never explore beyond. GitHub use translates into GitLab use, but not into general git use workout a central repository. > Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a stor…
And tbh, that's how it should be for a version control system. Before git with its byzantine workflows and a thousand ways to do the same thing, version control (e.g. svn) was a thing that's just humming along invisibly in the background, something that you never had to 'learn' or even think about, much like the filesystem.
I don't need to know how a filesystem works internally to be able to use it.
And having a centralized store and history helps a lot to keep a version control system conceptually simple.
Earlier quoted context omitted.
firefox development has been moved from mercurial to git since early november of 2023 https://www.phoronix.com/news/Firefox-Going-Git
Interesting that their issues are blamed on "dual SCM", not on Mercurial itself. I guess just the weight of contributors expecting Git as the default is sinking the big Mercurial projects these days.