[flagged]
If you had checked you would've seen issues are not enabled. I assume they still use their Bugzilla
> If you had checked you would've seen issues are not enabled
That was the point of the (obviously ill-received) joke.
Mozilla Firefox – Official GitHub repo
51–60 of 481 posts
Re: Mozilla Firefox – Official GitHub repo
#52Not for PRs or issues though which are arguably the biggest reasons to use GitHub. Still this is definitely an improvement.
So is this now just a mirror? I'm not sure what the point of moving to GitHub was then.
Re: Mozilla Firefox – Official GitHub repo
#53Pretty 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.
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.)
Git should have issue support or something like it as a convention but pull requests are an abomination that we are stuck with. No thank you.
Re: Mozilla Firefox – Official GitHub repo
#54Pretty 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.
ironically hardly anybody outside of the linux kernel community uses it the way it was intended lol. Didn't all this start with Linus getting into a spat with the bitkeeper dev involving some sort of punitive measure as a response to somebody making a reverse-engineered FOSS client? I don't remember the details and I'm sure I have at least half of them wrong, but that's easily one of the most disastrous decisions in…
> Didn't all this start with Linus getting into a spat with the bitkeeper dev
It's a joke that the bitkeeper dev has two revision control named after him, Mercurial and Git.
Re: Mozilla Firefox – Official GitHub repo
#55Earlier 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.
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.
It's impossible to disable PRs on GitHub, sadly. See https://github.com/dear-github/dear-github/issues/84
Re: Mozilla Firefox – Official GitHub repo
#56Pretty 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.
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…
IIRC Phabricator stored most of it's metadata in git-notes. In theory we could have been making tools compatible with such a format all this time.
Re: Mozilla Firefox – Official GitHub repo
#57Inevitable. GitHub is a good platform in need of some proper dev workflows (pull requests are atrocious, branches footguns, yml driven CI is a noose) but they've obviously won.
Re: Mozilla Firefox – Official GitHub repo
#58Pretty 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.
Turns out the important part wasn't the distributed-ness at all (unless you count being able to work offline). Many such cases.
Oh it is, but I think people forget what the distributed model gets you. It isn't just about having a completely decentralised workflow. When you clone a repo you have everything you need to keep working on that project. You have your own copy of all the branches which you are free to do whatever you want with. This is what makes it fast. Every clone has a brand new master branch and you never needed to ask anyone or get agreement to get your own branch to work on. Commits on your branch will never interfere with anyone else's work. You don't need to lock files and complete your work as quickly as possible. You can do as many commits as you like, a hundred in a day is not unheard of, because it's your branch. Previously people would commit once a day at most and sometimes not even until the end of the week, which is just unthinkable to a git user. A git clone is your own personal repo which allows you to use version control before you even share anything with anyone.
Re: Mozilla Firefox – Official GitHub repo
#59Pretty 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.
I find this comment really interesting, because NONE of my clients in the last 10 years of (self-) employment had even a single codebase on GitHub.
I am contributing to a few open source projects on GitHub here and there though.
Re: Mozilla Firefox – Official GitHub repo
#60Pretty 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.
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 story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git)
Radicle offers one. CLI-based, too.