Live data from Hacker News

Mozilla Firefox – Official GitHub repo

github.com

121–130 of 481 posts

Re: Mozilla Firefox – Official GitHub repo

#121
post #34

Earlier quoted context omitted.

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…

> 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.

Re: Mozilla Firefox – Official GitHub repo

#123
post #100
post #94

Earlier quoted context omitted.

Git wouldn't be mainstream without GitHub though.

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.

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.

Re: Mozilla Firefox – Official GitHub repo

#124
post #93
post #71

Earlier quoted context omitted.

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.

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.

The modern workflow is just to let GitHub squeeze yor shit commits into one and then rebasing that.

Re: Mozilla Firefox – Official GitHub repo

#125

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.

I wish I could search on GitHub without logging in

They used to have 64 core 32 machine cluster just for search. You may want to reduce unnecessary search. https://github.blog/engineering/the-technology-behind-github...

Re: Mozilla Firefox – Official GitHub repo

#126

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.

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?

Re: Mozilla Firefox – Official GitHub repo

#127

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.

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.

Re: Mozilla Firefox – Official GitHub repo

#128
post #60

Earlier quoted context omitted.

> 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…

> 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 fi…

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.

Re: Mozilla Firefox – Official GitHub repo

#129
post #75

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?

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.

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

Re: Mozilla Firefox – Official GitHub repo

#130
post #60
post #26

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…

"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".
Post reply on HN