(I work at Mozilla, but not on the VCS tooling, or this transition)
To give a bit of additional context here, since the link doesn't have any:
The Firefox code has indeed recently moved from having its canonical home on mercurial at hg.mozilla.org to GitHub. This only affects the code; bugzilla is still being used for issue tracking, phabricator for code review and landing, and our taskcluster system for CI.
In the short term the mercurial servers still exist, and are synced from GitHub. That allows automated systems to transfer to the git backend over time rather than all at once. Mercurial is also still being used for the "try" repository (where you push to run CI on WIP patches), although it's increasingly behind an abstraction layer; that will also migrate later.
For people familiar with the old repos, "mozilla-central" is mapped onto the more standard branch name "main", and "autoland" is a branch called "autoland".
It's also true that it's been possible to contribute to Firefox exclusively using git for a long time, although you had to install the "git cinnabar" extension. The choice between the learning hg and using git+extension was a it of an impediment for many new contributors, who most often knew git and not mercurial. Now that choice is no longer necessary. Glandium, who wrote git cinnabar, wrote extensively at the time this migration was first announced about the history of VCS at Mozilla, and gave a little more context on the reasons for the migration [1].
So in the short term the differences from the point of view of contributors are minimal: using stock git is now the default and expected workflow, but apart from that not much else has changed. There may or may not eventually be support for GitHub-based workflows (i.e. PRs) but that is explicitly not part of this change.
On the backend, once the migration is complete, Mozilla will spend less time hosting its own VCS infrastructure, which turns out to be a significant challenge at the scale, performance and availability needed for such a large project.
If I may - what were the significant scale challenges for self hosted solution?
bayindirh · 1m ago
I guess it's the CI/CD infrastructure. Pipeline and time requirement grows exponentially as the code supports more operating systems and configurations.
I used a GitLab + GitLab Runner (docker) pipeline for my Ph.D. project which did some verification after every push (since the code was scientific), and even that took 10 minutes to complete even if it was pretty basic. Debian's some packages need more than three hours in their own CI/CD pipeline.
Something like Mozilla Firefox, which is tested against regressions, performance, etc. (see https://www.arewefastyet.com) needs serious infrastructure and compute time to build in n different configurations (stable / testing / nightly + all the operating systems it supports) and then test at that scale. This needs essentially a server farm, to complete in reasonable time.
An infrastructure of that size needs at least two competent people to keep it connected to all relevant cogs and running at full performance, too.
So yes, it's a significant effort.
floriangosse · 1h ago
I think it's actually an understandable strategical move from Mozilla. They might loose some income from Google and probably have to cut the staff. But to keep the development of Firefox running they want to involve more people from the community and GitHub is the tool that brings most visibility on the market right now and is known by many developers. So the hurdle getting involved is much lower.
I think you can dislike the general move to a service like GitHub instead of GitLab (or something else). But I think we all benefit from the fact that Firefox's development continues and that we have a competing engine on the market.
fhd2 · 31m ago
In my experience, most contributors who are deterred from contributing because they can't use GitHub aren't particularly valuable contributors. I'm sure there's exceptions, but I haven't seen any for non-trivial open source projects I've been involved in. I might even argue that it could be good to have a slightly higher bar to deter low quality one time contributors.
arp242 · 6m ago
I spent quite some time writing a patch for FreeBSD and Linux a few months ago, including getting to grips with their contribution process.
Both patches have been ignored thus far. That's okay, I understand limited resources etc. etc. Will they ever be merged? I don't know. Maybe not.
I'm okay with all of this, it's not a complaint. It's how open source works sometimes. But it also means all that time I spent has been a waste. Time I could have spent on more/other patches.
So yeah, there's that.
It's certainly true that making the bar higher will reduce low-quality contributions, because it will reduce ALL contributions.
(aside: FreeBSD actually accepts patches over GitHub, but it also somewhat discourages that and the last time I did that it also took a long time for it to get reviewed, although not as long as now)
lpln3452 · 7m ago
Contribution isn’t driven by a desire for rewards, but by goodwill. Friction only gets in the way. If the friction is worth it, fine - but what exactly is being lost by moving the repository to GitHub?
berkes · 22m ago
You just showed the poster-child of gatekeeping that is harming Open Source.
Every contributor is valuable, it's in the name, the definition of "contribute".
Any bar to entry is bad, it certainly never is the solution to a different problem (not being able to manage all contributions). If anything, in the longer run, it will only make it worse.
Now, to be clear, while I do think GitHub is currently the "solution" to lower barriers, allow more people to contribute and as such improve your Open Source Project, the fact this is so, is a different and other problem - there isn't any good alternative to Github (with broad definitions of "good") why is that and what can we do to fix that, if at all?
sneak · 19m ago
Not all PRs are created equal.
berkes · 6m ago
And that is good.
Diversity, here too, is of crucial importance. It's why some Open Source software has sublime documentation and impeccible translations, while the other is technically perfect but undecipherable. It's why some Open Source software has cute logos or appeals to professionals, while the other remains this hobby-project that no-one ever takes serious despite its' technical brilliance.
rendaw · 7m ago
How can you judge the quality of people who don't contribute? They don't contribute, so what's there to judge?
Kuinox · 1h ago
It's good that they fixed one of the major tech debt for contributing to firefox.
When I tried a few years ago, mercurial took multiple hours to clone, and I already had to use the unofficial git support in order to have things working before the end of the day.
Their docs was also a mess back then and made me recompile everything even if it wasnt needed.
Now, both the desktop and the mobile version will be on Github, and the "issues" will stay on Bugzilla.
This will take advantage of both GitHub's good search and source browsing and Git's familiar system.
As a former Firefox and Thunderbird contributor, I have to say that I used local search instead of trying to find something on the mozilla-central website.
Of course, when you're actively developing software, you search inside your IDE, but allowing to find things easily on the website makes it more welcoming for potential new contributors.
adrian17 · 52m ago
> I have to say that I used local search instead of trying to find something on the mozilla-central website.
On the contrary, I find searchfox to be the best code navigation tool I used. It has nice cross-language navigation features (like jumping from .webidl interface definition to c++ implementation), it has always-on blame (with more features too) and despite that it's really fast and feels extremely lightweight compared to GitHub interface. I really wish I had this with more projects, and I'll be sad if it ever dies.
mritzmann · 1h ago
What is the source of “Firefox Moves to GitHub”? It could be a mirror, just like Linux also has an mirror on GitHub.
It’s interesting how pull requests remain the only tab (apart from code) that cannot be disabled by the repo owners.
I get it from GitHub’s perspective, it’s a nudge to get people to accept the core premise of ”social coding” and encouraging user pressure for mirrored projects to accept GitHub as a contribution entrypoint. I’m impressed by their successes and would attribute some of that to forced socialization practices such as not allowing PRs to be disabled. I’ve grown to dislike it and become disillusioned by GitHub over the course of a long time, but I’m in awe of how well it has worked for them.
mlenz · 3h ago
Great to see, but I wonder what lead to the decision of creating a new org instead of using github.com/mozilla
moontear · 2h ago
Without knowing their reason, there are a few things tied to the org where multiple orgs make sense. If you do SSO for example you tie the org to a SSO provider, you can’t tie „just a few users“ to the SSO provider (afaik). The Firefox repo may have totally different authentication / users than the main Mozilla repo.
GitHub are terrible at this, because you can't have levels other than Org and Repository. And many things (SSO, visibility rules, common configs) are on the org level.
Unfortunately often the cleaner option is to create a separate org, which is a pain to use (e.g. you log in to each separately, even if they share the same SSO, PATs have to be authorised on each one separately, etc).
In Gitlab, you would have had one instance or org for Mozilla, and a namespace for Firefox, another one for other stuff, etc.
captn3m0 · 2h ago
There is an “Enterprise” level above the org, but that obviously needs an Enterprise account. It lets you manage some policies across multiple orgs, including membership.
sofixa · 1h ago
But it still requires multiple orgs, and the UX is still poor.
It's like AWS accounts vs GCP projects. Yeah, there are ways around the organisational limitations, but the UX is still leaky.
thrdbndndn · 2h ago
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?
chme · 1h ago
Not a firefox dev, but pretty sure its 'main'
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.
jamienicol · 1h ago
I am a Firefox developer, and you're spot on. Previously there were separate hg repos for central, beta, release. I think ESRs too. And autoland. Now they're all branches in the same repo, and central is renamed main.
Commits land in autoland and get backed out if they cause test failures. That's merged to main ~twice per day when CI is happy
thrdbndndn · 42m ago
Thanks for the clarification!
I've mostly encountered these branches/repos when checking commits linked to Bugzilla tickets, and I don't recall seeing "autoland" show up too much in those cases.
bandrami · 2h ago
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.
SCdF · 2h ago
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)
nextaccountic · 1h ago
Unfortunately the project is not just code. It also has issues, PRs and other stuff. Github has two kinds of lock in, a) your stuff is there and if you move elsewhere you probably will wipe your issues etc (huge loss of institutional knowledge), and b) there is a network effect because everyone has a github account and people are used to just hop on a repository and file an issue (rather than being greeted by a log in page), cross-reference issues between repositories (hard to make work if repos aren't in the same site, unless both sites use some interop thing like activitypub which github will never use), etc
> 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)
There is https://github.com/git-bug/git-bug - would love if people started o use it, even in a read only way: use github issues normally, but also have a bot that saves all coments to git-bug, so that i can read issues without an internet connection. Then, at a later date, make it so that people that make issues on git-bug also gets the issue posted on github, making a two way bridge.
Then, optionally, at a later stage when almost everyone migrated to git-bug, make the github issues a read only mirror of the git-bug issues. Probably not worth it: you lose drive-by comments from newcomers (that already have a github account but probably never heard of git-bug), raising the friction to report bugs
SCdF · 51m ago
> Unfortunately the project is not just code.
The literal project we are discussing is just code. It's literally just code. It doesn't have issues, PRs are disabled as much as they can be (by a GitHub action that automatically closes all PRs with a note that code should be submitted elsewhere), and all "other stuff" is disabled.
What you are referring to is more of a mirror-like approach usage of GitHub.
Some big repos or organizations might be able to pull this off, but good luck having a small project and then directing users to go through all of those hoops to submit issues somewhere else, open PRs somewhere else, etc.
aktau · 23m ago
This is one area where Gerrit Code Review is (was? I don't know if it changed) is superior. It stores everything it knows about in git repositories (preferences in a separate meta git repository, comments, patches). With the right refspec, you can pull it all down and have a full backup.
mkingston · 36m ago
I was reading the git-bug documentation and found "bridges" to third-party platforms:
> 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.
flohofwoe · 1h ago
> They learn a set of narrow workflows and never explore beyond.
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.
baq · 1h ago
svn was not 'humming' unless you confined yourself to a very narrow set of functionality, e.g. merging was best left to experts.
flohofwoe · 1h ago
In a centralized version control system with a single history, branching and merging is also much less important.
In git, working on your own branch is essential to not step on other people's feet and to get a clean history on a single main/dev branch (and tbf, git makes this easy for devs and text files). With a centralized version control system, both problems don't even exist in the first place.
When we did game development with a team of about 100 peeps (about 80 of those non-devs, and about 99% of the data under version control being in binary files) we had a very simple rule:
(1) do an update in the morning when you come to work, and (2) in the evening before you leave do a commit.
Everybody was working on the main branch all the time. The only times this broke was when the SVN server in the corner was running full and we either had to delete chunks of history (also very simple with svn), or get more memory and a bigger hard drive for the server.
writebetterc · 1h ago
You don't need to learn how git works internally to be able to use it. You need to know a lot about filesystems in order to use them: Folders, files, symbolic links, copy, cut, paste, how folders can exist on different devices, etc. There's just a tonne of assumed knowledge regarding them, and it's very obvious when you meet someone that doesn't have it (regular people often don't have all it).
Subversion also isn't some thing humming along invisibly in the background, it has its own quirks that you need to learn or you'll get stung.
vishnugupta · 1h ago
svn was a nightmare when it came to handling conflicts. So at least for me, humming in the background wasn’t the term used for it at work.
guappa · 50m ago
Have you ever actually used svn?
flohofwoe · 8m ago
Yes for about 18 years(?) in teams up to about 100 people, working copy sizes up to about 150 GB (with most of the data being binary game asset files), and everybody working on trunk (we only used branches for releases which were branched off trunk but never merged back, only cherry-picking bugfixes from the main into release branches as needed).
We used TortoiseSVN as UI which worked well both for devs and non-devs.
With this sort of setup, git would break down completely if it weren't for awkward hacks like git-lfs (which comes with its own share of problems).
People could learn, if there was suddenly a need. Just like they learned the narrow workflows they use now.
laserbeam · 59m ago
> You could, but generally people can’t. They learn a set of narrow workflows and never explore beyond.
The point is you CAN. Joe can in theory do it, and Steve can make an alternative piece of software to do it for Joe. In most other centralized places (like social media), you CANNOT. Joe cannot take his data off of Facebook and interact with it outside of the platform or move it to another platform.
arp242 · 1h ago
"I only accept patches and bug reports over email" is just as much of a narrow set of workflows as "I only accept patches and bug reports through PRs".
account-5 · 2h ago
This is why I like fossil, it comes with most of the stuff I use built in, and you can deploy it as a website too. Use it for all of my personal projects and used it extensively for coursework at university.
sublinear · 2h ago
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.
rablackburn · 1h ago
>> I would love a good issue tracking system that is done entirely inside git
> 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)
Embrace, Extend..
(largely this is unfair, as plain git leaves much to be desired- but you can’t deny that the things surrounding git on github are very sticky).
blueflow · 36m ago
Lets pray that Microsoft won't use Github to find new ways to extract money.
wordofx · 1h ago
Build a bridge and…
frizlab · 1h ago
Like fossil?
kaichanvong · 1h ago
while --it-is possible seeing how fossil confuses, for the Github conversation, it's not really in the same category, conversation, some clever happenings happening within fossil-scm, however, it's not really the same as the problem design-led github solves given people saying downtimes; sure, git, github; however how people using github, different–similar, git, however, github.
However, were you to say liken-able (slang keywords: comparative something else--) of, "fossil with git-github", then again: no.
Good call were the conversation (comments, almost interchangeable at-times haha!) being, everyone use git for Firefox, something kinda wild-topic!
littlestymaar · 2h ago
> 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.
enos_feedler · 2h ago
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.
hnlmorg · 1h ago
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.
groestl · 2h ago
> 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.
baq · 1h ago
Maybe that's the reason everything tends to get centralized.
SCdF · 2h ago
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.
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.
tigroferoce · 2h ago
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.
arp242 · 1h ago
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.
xboxnolifes · 2h ago
Sure, but then we are no longer talking about git.
LtWorf · 46m ago
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.
phire · 1h ago
People have forgotten just how bad centralised version control was in 2005.
If you weren't connected to the internet, you couldn't do a thing. You couldn't checkout. You couldn't commit. You could create branches. The only thing on your computer was whatever you checked out last time you were connected to the server.
People talk about SVN, but it wasn't that common in 2005. None of the project hosting platforms (like SourceForge) supported SVN, they were all still offering CVS. If you wanted to use SVN, you had to set it up on your own server. (From memory, google code was the first to offer SVN project hosting in mid-2006). Not that SVN was much better than CVS. It was more polished, but shared all the same workflow flaws.
Before Git (and friends), nothing like pull-requests existed. If you wanted to collaborate with someone else, you either gave them an account on your CVS/SVN server (and then they could create a branch and commit their code), or they sent you patch files over email.
The informal email pull requests of git were an improvement... though you still needed to put your git repo somewhere public. Github and its web-based pull requests were absolutely genius. Click a button, fork the project, branch, hack, commit, push, and then create a formal "pull request". It was nothing like centralised project management systems before it. A complete breath of fresh air.
chgs · 32m ago
Pull requests aren’t part of git. They are a feature of one implementation.
guappa · 33m ago
A patch over email is how git works too!
IshKebab · 2h ago
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.)
qwertox · 2h ago
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.
sph · 1h ago
Given how terrible GitHub search in files is, what I usually do is clone the repo and run ripgrep.
nicce · 1h ago
If the repository is indexed, there isn’t really competitive search. You can find blog posts about it. They actually used ripgrep at some point. (not anymore I guess because too slow?).
But Github is actually pretty good at searching for something across all files in a repo.
eXpl0it3r · 1h ago
Not sure when you tried last, but it's gotten a lot better over the years. If you need something from the latest master, you'll be able to find it.
jimbob45 · 1h ago
That exact exercise filled a quarter of my workday today.
mmis1000 · 2h ago
I think it would be great if git have some kind of soft lock by default (like attach a text on some file without make it into actual commit). It could probably make peoples' live easier when you and teamates need to communicate what files you are changing thus reduce the chance of conflict.
mashlol · 55m ago
FWIW git lfs does have support for locking files.
spookie · 2h ago
Yeah, especially binaries.
mhh__ · 2h ago
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.
captn3m0 · 2h ago
Not Git, but several forges are working towards an ActivityOub based federation format for these: https://f3.forgefriends.org/
eru · 1h ago
Git was invented with pull requests in mind. It's just that they were originally meant to be sent via email, not on the web.
kace91 · 2h ago
Can you expand on that? I’m probably younger but I can’t imagine a more comfortable way to review code.
eru · 1h ago
Pull requests are great, but the typical github UI isn't necessarily the best way to review code.
It's often useful. But sometimes you want to use other tools, like firing up your editor to explore.
snickerbockers · 2h ago
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 the history of the software-business right up there with valve turning down minecraft and EA refusing to make sports games for the SEGA dreamcast (that last one isn't as well known but it led to SEGA launching the 2k sports brand to which outlasted the dreamcast and eventually got sold to a different company but otherwise still exists today and is still kicking EA's ass on basketball games).
eru · 1h ago
That's how git started.
But there were already quite a handful of other distributed version control systems around by the time git showed up.
So if Linus hadn't written git, perhaps we would be using darcs these days. And then we'd be debating whether people are using darcs the way it was intended. Or bazaar or monotone or mercurial etc.
I don't think what the original authors of any one tool intended matters very much, when there were multiple implementations of the idea around.
vintermann · 2h ago
> 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.
bitwize · 1h ago
I've heard the one that says much like Linux, Git is named after Linus himself.
midnightclubbed · 1h ago
EA not making sports games for Dreamcast wasn’t a bad decision for EA. It cost Sega a huge amount of money to produce and license their own sports games exclusively for Dreamcast, not having EA sports was a huge blow.
And while NBA 2k destroyed NBA Live it took until 2009 for that to start happening (long after Sega ownership), mainly down to sliding standards in EA’s NBA Live titles and eventually some disastrous EA launches.
rowanG077 · 1h ago
I don't see how EA creating their biggest rival is anything but a bad decision for them. Had they licenses they would have a monopoly and probably millions of more sales.
formerly_proven · 2h ago
It would've made sense to change many defaults in git for "normal users" ages ago (git 2?) instead of keeping the kernel-workflow defaults.
ghosty141 · 1h ago
I don't get this. Git is still distributed, even if the "main" repo is on github, everybody still has a local copy. You are confusing project management (which github effectively does) and git. Git is still git, github is just a project management tool with git integration.
In the Linux kernel the project management is done via email (which is also just a centralized webserver in the end), so whats the problem?
miyuru · 1h ago
The problem is lot of Dev tools has centralized on GitHub, so much so that we cannot use IPv6 only servers for development because GitHub does not support IPv6.
From what I use composer and brew relies on GitHub to work.
To be fair, Git itself is a bit of a pain, and GitHub's main achievement is/was to make it somewhat bearable.
casenmgreen · 2h ago
I regard the Git docs as being fully equal to scientific Wikipedia articles.
Everything is fully and completely explained, in terms which mean nothing.
eru · 1h ago
I find both Wikipedia and Git docs typically more useful than this. Much more.
(They ain't perfect, of course.)
spookie · 1h ago
To be fair, most of the its difficulty is realized when you're stuck with a teammate rewriting history. Who, much like anyone anyone doing the same, hasn't bothered reading a book explaining things.
jamienicol · 1h ago
That problem is solved by preventing forced pushes. Rewriting history locally is encouraged.
Tainnor · 1m ago
Prevent forced pushes on protected branches (develop, main, hotfix etc.). I don't care if somebody force pushes their private feature branch.
baq · 1h ago
If you don't rewrite history in git, I don't want to bisect in your repos.
If you push rewritten history to master, you're a git.
Conclusion: learn your tools.
mkesper · 1h ago
The modern workflow is just to let GitHub squeeze yor shit commits into one and then rebasing that.
baq · 41m ago
Hardly anything modern about it, but it's a way of keeping a somewhat sane history. Certainly better than merging 'fix' 'fix' 'fix comments' into master.
The thing, we could have done better (and have been) since before git even existed.
tester756 · 1h ago
No, git's CLI is terrible mess.
mmis1000 · 2h ago
In some sense, git is actually like advanced zip versioning system. A commit is literally just a snapshot of code base except it tell you what is the previous version of this version.
Also, git store the files in a smarter way so file size won't explode like zip versioning.
eru · 1h ago
> A commit is literally just a snapshot of code base except it tell you what is the previous version of this version.
Or previous versions. Plural. Yes.
Well, that's one half of git. The other half is tooling to work with the snapshots and their history, eg to perform merges.
johannes1234321 · 1h ago
The reason is that it is more than code. Managing identity is hard and for many projects besides having a source of truth for the repository you also need some degree of project management (bug tracking)
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.
eru · 1h ago
Yes, in git you get the benefit of fine-grained version control while you are still exploring.
Then later on for the PR, you can sanitise the whole thing for review.
In the bad old days, you only got the latter. (Unless you manually set up an unrelated repository for the former yourself.)
NexRebular · 1h ago
It really is a tragedy that git monoculture is winning over Mercurial, Fossil and other better designed alternatives. Don't even have a nice github-like service for Mercurial anymore as Bitbucket decided to give up.
baq · 2h ago
When you clone a repo you store it on your computer, too. Don’t confuse version control with CI servers/bug trackers/software forges.
novaRom · 1h ago
Linus Torvalds is one of those people whos impact on the world is significant even if he was not driven by financial initiative. It’s crazy how much one person can change things just by solving their own problems really well.
No comments yet
lmm · 2h ago
Turns out the important part wasn't the distributed-ness at all (unless you count being able to work offline). Many such cases.
globular-toast · 2h ago
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.
eru · 1h ago
> You have your own copy of all the branches which you are free to do whatever you want with.
That's the default. But git would work just as well, if by default it was only cloning master, or even only the last few commits from master instead of the full history.
You can get that behaviour today, with some options. But we can imagine an alternate universe were the defaults were different.
Most of what you say, eg about not needing lockfiles and being able to make independent offline commits, still applies.
globular-toast · 35m ago
The point wasn't really about having your own copy of the commit history, it's about having your own copy of the refs (which is all a branch is in git). Basically, your master branch is not the same branch as GitHub's master branch or anyone else's. This is one of the things people don't really seem to understand about git. It means you don't have to do the "feature branch" thing, for example, you can just do commits on your master branch then submit a PR.
spookie · 1h ago
Yup. It's an extremely powerful workflow, you won't fear trying new ideas, you aren't fully commited to them (hehe).
vasco · 2h ago
Most people have it at least in two places if they work alone and in many places if they work with others. Having a consistent central UI doesn't take away from the distributed part, while adding a bunch of goodies.
m-schuetz · 55m ago
I have no use for a distributed source control system. I want my stuff consolidated at one place.
csomar · 1h ago
distributed # decentralized. The point of distributed is to keep a copy of your own. The point of decentralized is to not have a central point of authority.
contravariant · 1h ago
I'm fine with it as long as ssh still works.
ahoka · 1h ago
Git wouldn't be mainstream without GitHub though.
dijit · 1h ago
It might feel like that now, but in 2011 github was just one of a bunch of code forges and at the time they were all similar in quality.
Gitorious was chosen for the meego/maemo team for example.
petepete · 1h ago
In those days GitHub probably had more eyes on it in a day then Gitorious did in a quarter.
And I am one of the people saddened by the convergence on a single platform.
But you can't deny, it's always been pretty great.
Barrin92 · 2h ago
It's no more surprising than the fact that we invented distributed protocols to talk online and yet people use gmail or Facebook rather than sending data over the wire themselves.
People who are very insistent on distributed solutions never seem to understand that the economic, social and organizational reasons for division of labor, hierarchy and centralization didn't suddenly go away.
OtomotO · 2h ago
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.
voidspark · 1h ago
GitHub is not Git.
Git is by far the most widely used VCS. The majority of code hosting services use it.
tester756 · 1h ago
Why should we care about what Linus invented?
littlestymaar · 2h ago
Moving to git is understandable (Mozilla was using mercurial) but Github, really?
It's not like the hairy C++ code base of Firefox will suddenly become less scary and attract more open source developers simply because it's moving to Github.
TZubiri · 1h ago
pretty cool that we have a distributed version control system but people still complain that the distributed version control system is not itself hosted on a public distributed version control system like a ouroubouros of transparency so transparent that you can't even see the thing and you lose it because you don't know where it is and you lose yourself in a maze of infinitely branching dependency tree of self hosted bug trackers and federated account systems so that you can keep track of your bug reports and compile the bug tracker from scratch and all of a sudden you are building linux and you want to report a linux bug, but you need to send an email so you build an HTTP server but you don't have a C compiler yet so you download the latest C source code, but you don't have a C compiler to compile it, so you just make a github account and learn to compromise on your ideals welcome to adulthood.
moralestapia · 2h ago
Care to explain?
joha4270 · 2h ago
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
kgeist · 2h ago
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.
nurumaik · 1h ago
Fully decentralized metadata so we can finally have merge conflicts in PR comments while discussing merge conflicts
joha4270 · 1h ago
Yes, as a I mentioned there is plenty of local copies of the code floating around.
Everything else... as the original comment said, is pretty centralized for a decentralized system.
aucisson_masque · 2h ago
Linus Torvalds invented git, which is what's used by GitHub and others like gitlab.
sorbusherra · 2h ago
which is also owned by microsoft, that uses github data to train large language model. So, after decades of trying to kill linux and sabotage it, they finally figured out how to own it.
masfoobar · 1h ago
As a Free software supporter, its just a matter of time before we lose out on our freedoms. Honestly, once Linus retires I do think Linux will continue to thrive with a good team but Linux, the kernel, will either have to adapt to current times (whatever that can be in the future) or something else will replace it and, likely, some AI aspect on top.
It wont be free software and, likely, it will be Microsoft.
tgsovlerkhgsel · 1h ago
On one hand, centralization at a commercial provider isn't great.
On the other hand, the plethora of different self-hosted platforms with limited feature sets is a huge pain. Just finding the repo is often a frustrating exercise, and then trying to view, or worse, search the code without checking it out is often even more frustrating or straight out impossible.
smallnix · 1h ago
I wish I could search on GitHub without logging in
hedayet · 1h ago
I wish that too, and I’ve always wanted to offer features like this in everything I build.
But it’s a lot of work to prevent abuse, especially for resource intensive features when supporting unsigned-in use cases.
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.
Kuinox · 1h ago
I tried to contribute a few years ago.
The mercurial clone was taking multiple hours.
They already had an non official git, which took 15 minutes to clone.
dgoldstein0 · 1h ago
Isn't mercurial abandonware? Or maybe I'm just remembering that gitlab dropped support. If it's not dead yet seems to be getting there
swiftcoder · 4m ago
It’s still used by Meta, at any rate (albeit a very scaled version thereof). Meta picked it for their monorepo when Linus wasn’t willing to play ball on extending Git for their use case.
arp242 · 2m ago
Is it still used there? I know they did in the past, but reading up a bit on the background on all of this I found https://github.com/facebook/sapling, and it seems that's what they're using now?
arp242 · 50m ago
They had a release just a few days ago. It's definitely not abandonware.
IshKebab · 2h ago
They supported Git and Hg until now. This means they are dropping Hg support.
kristel100 · 26m ago
Honestly surprised it took this long. For a project that depends so much on community contribution, being on GitHub just lowers the barrier for new devs. Curious to see if this revives contribution velocity.
berkes · 15m ago
In the very least, it will open up FTEs that can now work on what makes Mozilla projects unique, rather than on building and maintaining generic fundamentals.
It's a pet-peeve and personal frustration of mine. "Do one thing and do that well" is also often forgotten in this part of Open Source projects. You are building a free alternative to slack? spend every hour on building the free alternative to slack, not on selfhosting your Gitlab, operating your CI-CD worker-clusters or debugging your wiki-servers.
octocop · 1h ago
Nice, I was just checking yesterday to find the source code of firefox. Even if it is only a mirror it's a nice step to make it more available I think.
mentalgear · 1h ago
Would have been great if they used an European alternative ( like Codeberg ).
selectnull · 1h ago
Mozilla is US organization, why would they care to?
neilv · 1h ago
As for European specifically, maybe the commenter was talking about data protection laws. If not, maybe (in many European countries at the moment) less national or business background of ruthlessness.
I was thinking something different: I wonder whether Mozilla considered GitLab or Codeberg, which are the other two I know that are popular with open source projects that don't trust GitHub since it sold out to Microsoft.
(FWIW, Microsoft has been relatively gentle or subtle with GitHub, for whatever reason. Though presumably MS will backstab eventually. And you can debate whether that's already started, such as with pushing "AI" that launders open source software copyrights, and offering to indemnify users for violations. But I'd guess that a project would be pragmatically fine at least near term going with GitHub, though they're not setting a great example.)
pparanoidd · 1h ago
lol codeberg is down right now, bad timing
berkes · 10m ago
I've used Codeberg for some projects and while their work and services are impressive and their progress steady and good, it's really not a proper alternative to Github for many use-cases.
"It depends", as always, but codeberg lacks features (that your use-case may not need, or may require), uptime/performance (that may be crucial or inconsequential to your use-case), familiarity (that may deter devs), integration (that may be time-consuming to build yourself or be unnessecary for your case) etc etc.
IshKebab · 2h ago
Not for PRs or issues though which are arguably the biggest reasons to use GitHub. Still this is definitely an improvement.
baq · 2h ago
Which is fascinating since both suck. Gerrit (replace with whatever if you please) is a much better change submission experience and basically anything else is a better bug tracker.
The killer feature is collocation of features to a single forge, combined with a generous free tier it’s the windows xp of the ecosystem: everybody has it, everybody knows it, almost nobody knows anything else.
matkv · 2h ago
So is this now just a mirror? I'm not sure what the point of moving to GitHub was then.
rrr_oh_man · 2h ago
That's one way to close decades old bugs & feature requests
dtech · 2h ago
If you had checked you would've seen issues are not enabled. I assume they still use their Bugzilla
gbil · 2h ago
and they moved anyway the android firefox issues from github to bugzilla some time ago, it would be quite "funny" moving them back to github now
rrr_oh_man · 2h ago
> If you had checked you would've seen issues are not enabled
That was the point of the (obviously ill-received) joke.
calcifer · 2h ago
Ill-received or poorly stated? Try as I might, I can't find a joke in your comment.
nirava · 1h ago
I can. It was funny.
No serious engineer will read that line and think, "wow, how malicious of mozilla, they just made the move to close all bug reports at once".
arp242 · 48m ago
> No serious engineer will read that line and think, "wow, how malicious of mozilla, they just made the move to close all bug reports at once".
Never underestimate the cynicism of HN commenters.
DennisL123 · 1h ago
A BUILD.md could be useful.
mhh__ · 2h ago
Inevitable. 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.
jopsen · 1h ago
I don't Firefox is moving to Github Actions anytime soon. I was pretty involved with the TaskCluster setup years ago, and it still seems to be running a bunch of CI things.
mozilla-central has a LOT of tests -- each push burns a lot of compute hours.
rvz · 1h ago
Centralizing everything to GitHub really isn't a good idea given their frequent incidents every week.
petepete · 1h ago
I wonder how long it'll take for my PR which entirely removes the built in Pocket integration will take to be dismissed.
reddalo · 2h ago
Why GitHub? If they truly cared about open-source they would've chosen something else, such as a self-hosted Forgejo [1], or its most common public instance Codeberg [2].
I would argue that part of "truly caring" about open-source is being where the contributors and community are. That's probably a large part of the move to GitHub, and neither of these other options would achieve that. As much as one can say "git is distributed, the server doesn't matter", the centre of the community very much does matter, and for better or worse that's currently Github.
arccy · 29m ago
If you maintain a popular project, you'll quickly find that github prs are a massive source of spam and low quality prs with people that don't even bother to follow up.
Bad PRs all around, with just a constant stream of drive by "why no merge?!?!?!" comments.
protocolture · 2h ago
If they truly cared about open source they would have hosted their own git on a run down pentium 2 in a nerds basement, never washed, and spent most of their time complaining online.
freddie_mercury · 2h ago
To assert that an organisation doesn't "truly" care about open source simply because they've chosen a tool that isn't is ridiculous.
Even before this Mozilla almost certainly used hundreds of closed source tools, including things like Slack, Excel, Anaplan, Workday, etc.
Lightkey · 9m ago
Using proprietary software in-house for management is one thing, forcing outside contributors to use them, another. That is why they went out of their way to avoid Slack when the time came to leave IRC behind and they chose Matrix instead.
mzi · 2h ago
Codeberg unfortunately have an abysmal uptime track record.
rurban · 2h ago
I maintain some project on all forges in parallel, even savannah. Savannah is even the default. But 99% of all reports and contributions are on the github mirror, 1% on savannah, 0% on gitlab and 0% on codeberg. Nobody cares about those islands.
issues are stored in git bug and automatically synced. Github is the only viable option, but you can keep the others as mirrors when github chooses to strike you.
gsich · 2h ago
Probably only for visibility. Or MS is in the process of sponsoring them.
pndy · 1h ago
Considering image backlash they had over last year with: acquiring ad tech company created by former meta people, which in turn lead to introducing so-called "privacy preserving attribution" feature for ads tracking, changing ToS terms regarding data collection, firing CPO who was diagnosed with cancer. Then I do believe these all little changes are PR stunts with an attempt to regain trust of users who strongly criticised Mozilla in last year and earlier.
They should restructure instead, hire people who actually want to work on software and not use corporation and foundation around it as platform for their... peculiar "endeavours". But I doubt that's gonna happen - flow of Google cash and from all those naive people who think supporting Mozilla directly contributes to Firefox is too good it seems. But then it's understandable they do this - money from Google tap can get twisted.
aucisson_masque · 2h ago
> MS is in the process of sponsoring them.
Think you might be on something, with the incoming end of Google cash flow, Firefox may be in discussion with bing and that could be part of the agreement, use Microsoft server.
AStonesThrow · 2h ago
> If they truly cared about open-source
Perhaps Microsoft offered to pick up the tab that Google has been paying, but is now imperiled, or at least lend some sort of financial support, and Firefox cares more about paying their bills than open source
To give a bit of additional context here, since the link doesn't have any:
The Firefox code has indeed recently moved from having its canonical home on mercurial at hg.mozilla.org to GitHub. This only affects the code; bugzilla is still being used for issue tracking, phabricator for code review and landing, and our taskcluster system for CI.
In the short term the mercurial servers still exist, and are synced from GitHub. That allows automated systems to transfer to the git backend over time rather than all at once. Mercurial is also still being used for the "try" repository (where you push to run CI on WIP patches), although it's increasingly behind an abstraction layer; that will also migrate later.
For people familiar with the old repos, "mozilla-central" is mapped onto the more standard branch name "main", and "autoland" is a branch called "autoland".
It's also true that it's been possible to contribute to Firefox exclusively using git for a long time, although you had to install the "git cinnabar" extension. The choice between the learning hg and using git+extension was a it of an impediment for many new contributors, who most often knew git and not mercurial. Now that choice is no longer necessary. Glandium, who wrote git cinnabar, wrote extensively at the time this migration was first announced about the history of VCS at Mozilla, and gave a little more context on the reasons for the migration [1].
So in the short term the differences from the point of view of contributors are minimal: using stock git is now the default and expected workflow, but apart from that not much else has changed. There may or may not eventually be support for GitHub-based workflows (i.e. PRs) but that is explicitly not part of this change.
On the backend, once the migration is complete, Mozilla will spend less time hosting its own VCS infrastructure, which turns out to be a significant challenge at the scale, performance and availability needed for such a large project.
[1] https://glandium.org/blog/?p=4346
If I may - what were the significant scale challenges for self hosted solution?
I used a GitLab + GitLab Runner (docker) pipeline for my Ph.D. project which did some verification after every push (since the code was scientific), and even that took 10 minutes to complete even if it was pretty basic. Debian's some packages need more than three hours in their own CI/CD pipeline.
Something like Mozilla Firefox, which is tested against regressions, performance, etc. (see https://www.arewefastyet.com) needs serious infrastructure and compute time to build in n different configurations (stable / testing / nightly + all the operating systems it supports) and then test at that scale. This needs essentially a server farm, to complete in reasonable time.
An infrastructure of that size needs at least two competent people to keep it connected to all relevant cogs and running at full performance, too.
So yes, it's a significant effort.
I think you can dislike the general move to a service like GitHub instead of GitLab (or something else). But I think we all benefit from the fact that Firefox's development continues and that we have a competing engine on the market.
Both patches have been ignored thus far. That's okay, I understand limited resources etc. etc. Will they ever be merged? I don't know. Maybe not.
I'm okay with all of this, it's not a complaint. It's how open source works sometimes. But it also means all that time I spent has been a waste. Time I could have spent on more/other patches.
So yeah, there's that.
It's certainly true that making the bar higher will reduce low-quality contributions, because it will reduce ALL contributions.
(aside: FreeBSD actually accepts patches over GitHub, but it also somewhat discourages that and the last time I did that it also took a long time for it to get reviewed, although not as long as now)
Every contributor is valuable, it's in the name, the definition of "contribute".
Any bar to entry is bad, it certainly never is the solution to a different problem (not being able to manage all contributions). If anything, in the longer run, it will only make it worse.
Now, to be clear, while I do think GitHub is currently the "solution" to lower barriers, allow more people to contribute and as such improve your Open Source Project, the fact this is so, is a different and other problem - there isn't any good alternative to Github (with broad definitions of "good") why is that and what can we do to fix that, if at all?
Diversity, here too, is of crucial importance. It's why some Open Source software has sublime documentation and impeccible translations, while the other is technically perfect but undecipherable. It's why some Open Source software has cute logos or appeals to professionals, while the other remains this hobby-project that no-one ever takes serious despite its' technical brilliance.
Their docs was also a mess back then and made me recompile everything even if it wasnt needed.
Now, both the desktop and the mobile version will be on Github, and the "issues" will stay on Bugzilla.
This will take advantage of both GitHub's good search and source browsing and Git's familiar system.
As a former Firefox and Thunderbird contributor, I have to say that I used local search instead of trying to find something on the mozilla-central website.
Of course, when you're actively developing software, you search inside your IDE, but allowing to find things easily on the website makes it more welcoming for potential new contributors.
On the contrary, I find searchfox to be the best code navigation tool I used. It has nice cross-language navigation features (like jumping from .webidl interface definition to c++ implementation), it has always-on blame (with more features too) and despite that it's really fast and feels extremely lightweight compared to GitHub interface. I really wish I had this with more projects, and I'll be sad if it ever dies.
https://github.com/torvalds/linux
// EDIT: Source: https://news.ycombinator.com/item?id=43970574
https://github.com/mozilla-firefox/firefox/blob/main/.github...
I get it from GitHub’s perspective, it’s a nudge to get people to accept the core premise of ”social coding” and encouraging user pressure for mirrored projects to accept GitHub as a contribution entrypoint. I’m impressed by their successes and would attribute some of that to forced socialization practices such as not allowing PRs to be disabled. I’ve grown to dislike it and become disillusioned by GitHub over the course of a long time, but I’m in awe of how well it has worked for them.
https://wiki.mozilla.org/GitHub#other_github
Unfortunately often the cleaner option is to create a separate org, which is a pain to use (e.g. you log in to each separately, even if they share the same SSO, PATs have to be authorised on each one separately, etc).
In Gitlab, you would have had one instance or org for Mozilla, and a namespace for Firefox, another one for other stuff, etc.
It's like AWS accounts vs GCP projects. Yeah, there are ways around the organisational limitations, but the UX is still leaky.
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.
Commits land in autoland and get backed out if they cause test failures. That's merged to main ~twice per day when CI is happy
I've mostly encountered these branches/repos when checking commits linked to Bugzilla tickets, and I don't recall seeing "autoland" show up too much in those cases.
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)
> 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)
There is https://github.com/git-bug/git-bug - would love if people started o use it, even in a read only way: use github issues normally, but also have a bot that saves all coments to git-bug, so that i can read issues without an internet connection. Then, at a later date, make it so that people that make issues on git-bug also gets the issue posted on github, making a two way bridge.
Then, optionally, at a later stage when almost everyone migrated to git-bug, make the github issues a read only mirror of the git-bug issues. Probably not worth it: you lose drive-by comments from newcomers (that already have a github account but probably never heard of git-bug), raising the friction to report bugs
The literal project we are discussing is just code. It's literally just code. It doesn't have issues, PRs are disabled as much as they can be (by a GitHub action that automatically closes all PRs with a note that code should be submitted elsewhere), and all "other stuff" is disabled.
https://github.com/mozilla-firefox/firefox
Some big repos or organizations might be able to pull this off, but good luck having a small project and then directing users to go through all of those hoops to submit issues somewhere else, open PRs somewhere else, etc.
https://github.com/git-bug/git-bug/blob/master/doc/usage/thi...
I have not tried it.
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.
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.
In git, working on your own branch is essential to not step on other people's feet and to get a clean history on a single main/dev branch (and tbf, git makes this easy for devs and text files). With a centralized version control system, both problems don't even exist in the first place.
When we did game development with a team of about 100 peeps (about 80 of those non-devs, and about 99% of the data under version control being in binary files) we had a very simple rule:
(1) do an update in the morning when you come to work, and (2) in the evening before you leave do a commit.
Everybody was working on the main branch all the time. The only times this broke was when the SVN server in the corner was running full and we either had to delete chunks of history (also very simple with svn), or get more memory and a bigger hard drive for the server.
Subversion also isn't some thing humming along invisibly in the background, it has its own quirks that you need to learn or you'll get stung.
We used TortoiseSVN as UI which worked well both for devs and non-devs.
With this sort of setup, git would break down completely if it weren't for awkward hacks like git-lfs (which comes with its own share of problems).
The point is you CAN. Joe can in theory do it, and Steve can make an alternative piece of software to do it for Joe. In most other centralized places (like social media), you CANNOT. Joe cannot take his data off of Facebook and interact with it outside of the platform or move it to another platform.
You might like git-bug:
https://github.com/git-bug/git-bug
Embrace, Extend..
(largely this is unfair, as plain git leaves much to be desired- but you can’t deny that the things surrounding git on github are very sticky).
However, were you to say liken-able (slang keywords: comparative something else--) of, "fossil with git-github", then again: no.
Good call were the conversation (comments, almost interchangeable at-times haha!) being, everyone use git for Firefox, something kinda wild-topic!
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.
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.
That's how we started out.
For the actual event we are commenting on, they have disabled all features other than code hosting and PRs.
It's very silly they have to do this, but at least they can I suppose.
Sad to see that Mozilla is becoming less and less what they promised to be once Google funding are depleting.
If you weren't connected to the internet, you couldn't do a thing. You couldn't checkout. You couldn't commit. You could create branches. The only thing on your computer was whatever you checked out last time you were connected to the server.
People talk about SVN, but it wasn't that common in 2005. None of the project hosting platforms (like SourceForge) supported SVN, they were all still offering CVS. If you wanted to use SVN, you had to set it up on your own server. (From memory, google code was the first to offer SVN project hosting in mid-2006). Not that SVN was much better than CVS. It was more polished, but shared all the same workflow flaws.
Before Git (and friends), nothing like pull-requests existed. If you wanted to collaborate with someone else, you either gave them an account on your CVS/SVN server (and then they could create a branch and commit their code), or they sent you patch files over email.
The informal email pull requests of git were an improvement... though you still needed to put your git repo somewhere public. Github and its web-based pull requests were absolutely genius. Click a button, fork the project, branch, hack, commit, push, and then create a formal "pull request". It was nothing like centralised project management systems before it. A complete breath of fresh air.
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.)
Edit: ripgrep was just a test
More: https://github.blog/engineering/the-technology-behind-github...
It's often useful. But sometimes you want to use other tools, like firing up your editor to explore.
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 the history of the software-business right up there with valve turning down minecraft and EA refusing to make sports games for the SEGA dreamcast (that last one isn't as well known but it led to SEGA launching the 2k sports brand to which outlasted the dreamcast and eventually got sold to a different company but otherwise still exists today and is still kicking EA's ass on basketball games).
But there were already quite a handful of other distributed version control systems around by the time git showed up.
So if Linus hadn't written git, perhaps we would be using darcs these days. And then we'd be debating whether people are using darcs the way it was intended. Or bazaar or monotone or mercurial etc.
I don't think what the original authors of any one tool intended matters very much, when there were multiple implementations of the idea around.
It's a joke that the bitkeeper dev has two revision control named after him, Mercurial and Git.
And while NBA 2k destroyed NBA Live it took until 2009 for that to start happening (long after Sega ownership), mainly down to sliding standards in EA’s NBA Live titles and eventually some disastrous EA launches.
In the Linux kernel the project management is done via email (which is also just a centralized webserver in the end), so whats the problem?
From what I use composer and brew relies on GitHub to work.
https://github.com/orgs/community/discussions/10539
Everything is fully and completely explained, in terms which mean nothing.
(They ain't perfect, of course.)
If you push rewritten history to master, you're a git.
Conclusion: learn your tools.
The thing, we could have done better (and have been) since before git even existed.
Also, git store the files in a smarter way so file size won't explode like zip versioning.
Or previous versions. Plural. Yes.
Well, that's one half of git. The other half is tooling to work with the snapshots and their history, eg to perform merges.
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.
Then later on for the PR, you can sanitise the whole thing for review.
In the bad old days, you only got the latter. (Unless you manually set up an unrelated repository for the former yourself.)
No comments yet
That's the default. But git would work just as well, if by default it was only cloning master, or even only the last few commits from master instead of the full history.
You can get that behaviour today, with some options. But we can imagine an alternate universe were the defaults were different.
Most of what you say, eg about not needing lockfiles and being able to make independent offline commits, still applies.
Gitorious was chosen for the meego/maemo team for example.
And I am one of the people saddened by the convergence on a single platform.
But you can't deny, it's always been pretty great.
People who are very insistent on distributed solutions never seem to understand that the economic, social and organizational reasons for division of labor, hierarchy and centralization didn't suddenly go away.
I am contributing to a few open source projects on GitHub here and there though.
Git is by far the most widely used VCS. The majority of code hosting services use it.
It's not like the hairy C++ code base of Firefox will suddenly become less scary and attract more open source developers simply because it's moving to Github.
Sure, there would be local copies everywhere, but for a distribution version control system, it's pretty centralized at GitHub
Everything else... as the original comment said, is pretty centralized for a decentralized system.
It wont be free software and, likely, it will be Microsoft.
On the other hand, the plethora of different self-hosted platforms with limited feature sets is a huge pain. Just finding the repo is often a frustrating exercise, and then trying to view, or worse, search the code without checking it out is often even more frustrating or straight out impossible.
But it’s a lot of work to prevent abuse, especially for resource intensive features when supporting unsigned-in use cases.
https://www.phoronix.com/news/Firefox-Going-Git
It's a pet-peeve and personal frustration of mine. "Do one thing and do that well" is also often forgotten in this part of Open Source projects. You are building a free alternative to slack? spend every hour on building the free alternative to slack, not on selfhosting your Gitlab, operating your CI-CD worker-clusters or debugging your wiki-servers.
I was thinking something different: I wonder whether Mozilla considered GitLab or Codeberg, which are the other two I know that are popular with open source projects that don't trust GitHub since it sold out to Microsoft.
(FWIW, Microsoft has been relatively gentle or subtle with GitHub, for whatever reason. Though presumably MS will backstab eventually. And you can debate whether that's already started, such as with pushing "AI" that launders open source software copyrights, and offering to indemnify users for violations. But I'd guess that a project would be pragmatically fine at least near term going with GitHub, though they're not setting a great example.)
"It depends", as always, but codeberg lacks features (that your use-case may not need, or may require), uptime/performance (that may be crucial or inconsequential to your use-case), familiarity (that may deter devs), integration (that may be time-consuming to build yourself or be unnessecary for your case) etc etc.
The killer feature is collocation of features to a single forge, combined with a generous free tier it’s the windows xp of the ecosystem: everybody has it, everybody knows it, almost nobody knows anything else.
That was the point of the (obviously ill-received) joke.
No serious engineer will read that line and think, "wow, how malicious of mozilla, they just made the move to close all bug reports at once".
Never underestimate the cynicism of HN commenters.
mozilla-central has a LOT of tests -- each push burns a lot of compute hours.
[1] https://forgejo.org/ [2] https://codeberg.org/
Bad PRs all around, with just a constant stream of drive by "why no merge?!?!?!" comments.
Even before this Mozilla almost certainly used hundreds of closed source tools, including things like Slack, Excel, Anaplan, Workday, etc.
issues are stored in git bug and automatically synced. Github is the only viable option, but you can keep the others as mirrors when github chooses to strike you.
They should restructure instead, hire people who actually want to work on software and not use corporation and foundation around it as platform for their... peculiar "endeavours". But I doubt that's gonna happen - flow of Google cash and from all those naive people who think supporting Mozilla directly contributes to Firefox is too good it seems. But then it's understandable they do this - money from Google tap can get twisted.
Think you might be on something, with the incoming end of Google cash flow, Firefox may be in discussion with bing and that could be part of the agreement, use Microsoft server.
Perhaps Microsoft offered to pick up the tab that Google has been paying, but is now imperiled, or at least lend some sort of financial support, and Firefox cares more about paying their bills than open source