Those 3 lines look nicer than the "3 commands to install Gentoo"!

https://web.archive.org/web/20160309055829/http://www.bash.o...

Beautiful. Now I can finally do the necessary custom build: Replace all keyboard shortcuts with emacs ones.

I'm curious, can you elaborate on what's missing at GH/GL?

I use GitHub everyday, and problems, or what I miss from the mozilla stuff are:

- git is not as modern as mercurial (no absorb, no evolve, no nice ncurse gui, weird explicit branching model). I've been using both daily for more than ten years, but mercurial is largely superior in every respect

- no way to properly do patch stacks and proper reviews, with static analysis and linting integrated into the review tool, no way to lose comments by force push or that kind of thing (phabricator is amazing)

- no way to properly do private issues for security bugs or touchy audits that could reveal large problems

- no hierarchical categories for issues, no severity, priority, little provision for advanced filtering for a project our size. Bugzilla is very nice and much better than anything else I've tried. You can use tags for a lot of that on gh but it's messy - code browsing is primitive compared to https://searchfox.org/ (but most code browsing tool are, in comparison)

- my notifications are completely flooded by lots of useless information on GitHub, but that might be fixable

- our CI system (treeherder/taskcluster) scales, works on Linux/Mac/windows/Android and a bunch of version and arch, integrated with all of the other tools mentioned. Things such as auto-running tests based on the content of the patch, automatic categorization and prioritization of intermittent test failures, or auto-recording test failures and offering a pernosco recording showing the issue are just some of the features that we use daily without even thinking

There's probably a lot of other stuff that is better, but that's a nice start. If GitHub had a real patch stack management story, a real issue tracker and a real review tool it would go a long way, but that's not the case.

That's one of the few comments where someone says that Mercurial is better than Git. Interesting to me because I have used Mercurial and I like it, I now do mostly Git because that's what everyone uses. And I kind of prefer Git now because I grew more experienced with it, but really, that's a wash, they are both great and fundamentally very similar.

I had some coworkers who preferred Mercurial, the argument tends to be that it has a better user interface (not hard to beat Git on that one...), but also because of its immutability. Core Mercurial makes it really hard to change history, and branches are strongly tied to commits instead of being moving bookmarks (I know that Mercurial has bookmarks, but we used branches). Simple and stable.

Now the arguments you give for Mercurial are absorb and evolve, commands designed for rewriting history, something that we felt Mercurial tried so hard to make difficult (for example by hiding them behind extensions). Something I find quite interesting, has Mercurial changed so much during last years? Maybe that's what you mean by "modern" even though they came out at almost the same time.

About GitHub. The simplicity of its bug tracker is supposed to be a feature. Too often, we find ourselves with all sorts of fields that ultimately doesn't serve much purpose. For example, what about priority and severity? I understand priority: sort by priority to pick the ones you should work on, but then, what's the point of severity? If both are correlated, one of them is redundant, if they are not, which one should I pay attention to? And what's the severity of a feature request? And am I allowed to make the cosmetic feature I really want a critical priority?

GitHub has tags and a description, this can already do a lot. It is messy, but real life is messy, and often, in bug trackers with lots of fields and categories, I don't know what to put in there because it doesn't really apply, but I still put something because I have to, contributing to noise, which is also messiness but shifted elsewhere.

This is not a criticism of the Mozilla way, just that there is more than one way of doing things.

FWIW when you open a bug on bugzilla you don't have to fill all those fields. You fill a few, and others can be changed later - by yourself, people who triage, process it, fix the bug etc.

GH issues as a bug tracker feels really too simplistic compared to proper bug trackers. You can work around the deficiencies with labels and github actions to some extent, but it always feels like a hack. Why invent some ad-hoc labels with unclear meaning if you can use a superior bug trackers where you have fields as a first class citizen?

Although with GH, when you use all of those, the issue list still looks visually nice. Compared to GitLab, where if you go to GL tracker on GL project, you see issue list with 100 labels on each items, of different colors, the UI of the issue list is a madness.

(Been using GH on a daily basis at bigcorp for years for code tracking, but tickets are usually tracked in a behemoth like jira. I opened a few bugs in bugzilla over the years.)

Going deeper, this is like discussion about "static types vs dynamic types" or "relational DB vs freeform JSON" and so on.

Having dynamic types and freeform JSON sounds nice when doing toy things, but at some point you're like "hmm I want to find all bugs which affected Component X and have been fixed between version 83 and 90" and then some structure is good. (Arguably, GH issues labels could be used for this though.)

Can you explain what you mean by "patch stack"? I can roughly guess what you meant but not sure. Do you mean rebasing changes while to preserving the diffs of what you were reviewing? (I find that essentially no Git service I have used does this well)

Personally I think I got used to Git since it's 99.99% of what I use today. There are definitely pain points to it, but just like most people it's kind of become "the way it is", which I don't think is healthy. While Git has helped revolutionized the way SCM works, it's far from perfect (and it still does certain things worse than a traditional centralized SCM like binary file management and renaming files), and I think its prevalence sometimes puts people in a collective blindspot/groupthink. Imagine if you are in your 20's and Git is the only SCM you have used, everything other than Git would either be old-school or weird.

I definitely agree on GitHub though. I think it's quite nice for small projects (I manage one myself) but I don't see how it's usable for a serious large software project for reasons you mentioned. Even simple things like correctly linking issues together, or code review tools just seem severely lacking to me.

https://firefox-source-docs.mozilla.org/contributing/stack_q.... It's then two clicks to diff two arbitrary versions of a particular patch. For complex patch sets that take a few rounds of review, it's nice to understand what changed since last time you looked at it. When reviewing code from e.g. a beginner, it helps to quickly check that all comments have been addressed and nothing else has changed, etc.

Then you merge ("land") the patch stack in one unit, and it's tested in one unit, and bisection tooling knows that it is the case and it's nice.

Searchfox looks pretty cool, I'm surprised I've never heard of it. I often wonder how many great softwares are out there, but only used in a small niche.

It works for other code bases than Firefox, e.g. we index LLVM and webkit. It has a special understanding of the Firefox code, though.

Here's a cool class diagram with emojis: https://asuth.searchfox.org/mozilla-central/query/default?q=...