Live data from Hacker News

Mozilla Firefox – Official GitHub repo

github.com

161–170 of 481 posts

Re: Mozilla Firefox – Official GitHub repo

#161
post #75

Earlier quoted context omitted.

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

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.

Re: Mozilla Firefox – Official GitHub repo

#162
post #93

Earlier quoted context omitted.

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.

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 is, we could have done better (and have been) since before git even existed.

Re: Mozilla Firefox – Official GitHub repo

#163
post #155

Earlier quoted context omitted.

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

> 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. https://github.com/mozilla-firefox/firefox

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.

Re: Mozilla Firefox – Official GitHub repo

#164
post #97
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…

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

Lets pray that Microsoft won't use Github to find new ways to extract money.

Re: Mozilla Firefox – Official GitHub repo

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

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

I was reading the git-bug documentation and found "bridges" to third-party platforms:

https://github.com/git-bug/git-bug/blob/master/doc/usage/thi...

I have not tried it.

Re: Mozilla Firefox – Official GitHub repo

#166
post #121

Earlier quoted context omitted.

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

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.

Re: Mozilla Firefox – Official GitHub repo

#167
post #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…

A patch over email is how git works too!

Re: Mozilla Firefox – Official GitHub repo

#168

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

Thanks for the added context.

If I may - what were the significant scale challenges for self hosted solution?

Re: Mozilla Firefox – Official GitHub repo

#169
post #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…

Pull requests aren’t part of git. They are a feature of one implementation.

Re: Mozilla Firefox – Official GitHub repo

#170

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

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