The latter is ahead in network effects in a massive way - but I always preferred Mercurial. I'd have used it more but - network effects! - used git because of the projects I was working on.

The main thing was that the mental model of Mercurial fit in my head and the CLI was predictable and regular, whilst the tool still scaled to large codebases.

I find Git wants me to think about its implementation details and internal terminology at unpredictable moments during use. It still gets the job done but it feels like doing random CAPTCHAs in the midst of my work.

For Mercurial, that was shallow clones. I haven't looked at it in a while, but a quick googling shows me a wiki page where they discuss how an implementation could look like, and it hasn't been updated since 2015.

Network effects are certainly a reason git is popular. But also: If you want to challenge git, you should be able to compete with its basic features.

My workflow in Git centers on the index, and making lots of commits on local branches that will never get pushed. I spend a day working, rewrite history, stash a bunch of unrelated changes on temporary branches, and then send a couple commits on the main branch for code review.

When I used Mercurial for work, it felt surreal to have all of those weird little workflows get locked away behind plugins. I get how Mercurial is way easier for people starting out, and I also get that I could just use the plugins, but when I use Git, all those history-rewriting tools are right there where I want them.

But it's definitely missing git's rebase :)

This is what we're seeing here, IMHO.

*: There's nothing "objectively something" in computer science, because it's all is a pile trade-offs to get the desired result.

Mercurial vs. Git is IMHO a textbook example of "good enough with large user base" beats "subtly superior with smaller user base" over the long term.

---

looked it up, the feature is called "bookmarks" and was added in 2010. And even after added, all tbe tutorials ignored them. no idea if they are the recommended workflow now but if not then you probably don't get why git is superior to hg

Hg was indeed better than git, especially in the early days. But as git added features, made sane default choices more common, and cleaned up the CLI a bit, it doesn't matter now. They all do roughly the same thing, but the Hg workflow was still better imo because they just worked more intuitively coming from never using any DVCS before.

Git has better performance for a lot of users in a lot of use cases. Git is certainly not always better-performing than Mercurial, but it is often better performing, and the performance differences have varied at different points in time.

Some parts of Mercurial struck me as obviously better than Git, like the overall CLI UX, but some of the differences just seem like differences that come with tradeoffs. Mercurial is somewhat more opinionated about branches and allows some weird scenarios like “branches with multiple heads”, whereas in Git, a branch is just a label for one of the heads in the first place. Git’s index seems to trip up a lot of beginners, but as a long-time Git user, I don’t know how I could live without it.

I can see why people say “subtly superior”, but I think the superiority is overstated. The CLI UX is the only part where it seems like Mercurial has a clear advantage (and maybe better support for large files).

Mercurial labels everything on the graph. Multiple heads. many branches, a working copy, a tip. Manual merges, mandatory merge revisions, oh my...

Very neat for enabling collaboration, very easy for a computer to handle, very simple to implement, but very hard to process for a human. Also very hard to follow provenance.

How we came here? X merges, Y branches, Z commits, a curvy journey through the graph. An unbounded art which needs time to grasp.

Git is simpler. Divergences are branches. You add commits at the top of that branch. The place you're looking is the head. Simple, more stupid, a more clunky approach which enables many more things.

How we did come here? Branched at X, added n commits, Y merged along the way, m more commits and ta da. Who added these commits and when? A on Monday, B on the weekend. D merged their work on next Tuesday, and I did mine on today at 10.

Want to chop of specific parts off? Possible. Fork from a branch? Possible. These are things mentally easier to visualize. Mercurial can do these too, but it's more work, more mental effort and more complex to visualize.

Mercurial might be a better DVCS for nerds, but Git keeps is simple as possible and gets the job done well. This is why many people prefer it, incl. me.

Fossil is also a good idea with very high mental load. An idea which is searching for a problem, but I digress...

Of all the adjectives used to describe Git, “simple” seems to me the least appropriate.

Yes, the internal Git implementation is a “simple” DAG of content hashes, but the rest of the plumbing leaks so badly into user space you can’t begin to call using Git “simple”.

However, the mental model required by Git is much simpler than Mercurial, or at least designed to be presentable in a much simpler manner, and this counts for many folks, even if these people can work with much more complex mental models.

At the end of the day, our attention span and power is limited.

[0]: https://en.wikipedia.org/wiki/Git#Naming

The superiority of Mercurial works against it, because while https://xkcd.com/1597/ is entirely relatable, people are used to Git's specific flavour of incomprehensibility. It's normal, and the lore helps folk avoid the sharp edges most of the time.

Meanwhile, you're saying git is aligned with how people think merely because it got more mindshare early on.

And no, it's not how people think, nor how git shows it. Git shows changes as diffs, while it operates on compressed snapshots.

but there are operations that get the diffs (interactive rebase for example)

so, git, in typical UNIX fashion, is a bit of this and that, a very useful collection of tools to work on a repository, under some allegorical unification umbrella.

Unpacked commits are snapshots.

It's quite neat, the object DAG is the canonical representation, but we can optimise on one side for efficient storage and on the other side for our preferred visual representation. Both without particularly needing to worry about the canonical representation being an abstraction, as it's quite good at not being a leaky abstraction.

Git is, per the XKCD, a really neat graph system. There's not much that's special about that, though. Now it exists, we can write another just like it as a programming tutorial. The UI is better than it used to be, that's pretty much the best that can be said about it. But if you know the magic incantations you need to interact with it, and especially if you're using IDEs, it's really no worse than CVS.

The biggest difference between git and MySQL is that the former is solid underpinnings but poor UI and the latter is poor underpinnings but easy to deploy. In both cases, the foibles are well enough known that most folk don't need to worry about them, and and most projects I've worked on would derive no benefit from switching to a different system that's only going to confuse people.

I say this as someone who appreciates the graph, but has occasionally resorted to invoking plumbing directly because I can't work out which plumbing commands would do what I wanted.

I've recently wrote a post about it - how we're kinda locked with git and how other solutions have it hard to get adoption.

git was good, but github cemented git's position. So unless GitHub allows other solutions, then we're kinda locked.

>So what's the issue here? I'm worried that just because GitHub is so good, then unless they decouple from git as letters management engine and allow any/other, then we will be locked with git.

https://trolololo.xyz/github

I just use Mercurial with the git extension. Works fine.

I expect google to switch to that.

People probably view dealing with the FF codebase as part of Problem A, dealing with mercurial is Problem B, which is must less appreciated.

I tried to work on a Mercurial-based project (not firefox) but eventually gave up and just used git to track my changes and then prepare, very carefully, specific big merged commits to contribute back. It was easier, because I could never figure out how to clean up properly if I made a mistake -- so this way, I could just wipe the local copy and start over instead. But it was annoying, and I was glad to stop using it.

Completely bewildered by every thread about mercurial full of people proclaiming its advantages and "simpler mental model". Simpler than a DAG with pointers? Sure.

If I remember correctly you even needed to install some kind of external plugin just to do simple rebasing / branch cleanup. Now's the part where you tell me I'm doing it wrong, shouldn't be rebasing etc etc, but I'm just saying, it didn't work for me; and the constant claims that it's somehow objectively "better" but misunderstood get really boring.

This is actually superior in most cases. Being able to force rewrite history so easily in git was a design mistake imo.

[1] You can still change published history if you try hard enough with a lot of co-ordination.

If Mercurial doesn't support cleaning up of commits, then the commit history of Mercurial itself [2] wouldn't look so clean.

[2]: https://foss.heptapod.net/mercurial/mercurial-devel/-/commit...

Git only ever advocated for rebase, squash, and cherry pick for local branches that haven’t been pushed or shared yet. It is arguably not even “history” until you publish it. There have always been strong warnings about doing those things to published histories. It’s bad form generally speaking to do it (rebase or change history) to a published branch that more than 1 person is using for any other reason than extreme necessity, such as cleaning up security accidents where someone pushed keys or info they weren’t supposed to. And for exactly that reason, all the opinionated DVCSs that claim to consider history “sacred” actually offer the ability to easily rewrite published history, including Hg and Fossil!

Git’s ability to rewrite local history is pretty important for (1) encouraging a commit-early commit-often workflow where the local repo is a safe space, (2) cleaning up your work to make it presentable and semantically organized before sharing/publishing, and (3) allowing real-world workflows where people didn’t plan every single feature branch in advance but happened to end up working on multiple things and committing them first.

A version control system should be, first and foremost, a safety net that simply backs up any work you do without judgement. Personally, I consider the idea that commit history is sacred to be dogmatic and unnecessary. I’m open to the idea that it might help prevent a few specific types of accidents here and there, and it might be fair to argue that offering tools to groom the history’s presentation, separately from the log of commit activity, is on average a slightly better idea than having to actually reorganize commits before pushing them. Maybe that didn’t occur to git devs before it was released, or maybe it did and they decided it wasn’t going to help anyone and just add confusion to have two separate timelines. I don’t see any reasons justifying calling git’s design a ‘mistake’, and there seems to be evidence that most people are fine with git, and that for whatever reason the DVCSs that reacted to git in 2005 by immediately trying to fix some of git’s perceived issues didn’t ultimately fix the problem well enough to gain traction.

Being able to lie about what changes took place, what methods might have been tried by scrapped, and other small things possibly considered "noise at the time" often end up being valuable clues during maintaining that code years later.

>Are you very familiar with git and understand what workflows the git history rewriting tools were intended for, and how they’re typically used and supposed to be used?

Yes, intention for the tools, and the way people end up using them are not 1:1.

The potential for mistakes and information hiding is higher when you can rewrite history.

> Git only ever advocated for rebase, squash, and cherry pick for local branches that haven’t been pushed or shared yet.

Just because they advocate using it the right way, they enable using it the wrong way so people will use it the wrong way, and that's a guarantee of humans.

>It is arguably not even “history” until you publish it.

If you committed it, it's history.

If you're trying to make the claim of local history having no utility, thats a different argument imo.

> There have always been strong warnings about doing those things to published histories. It’s bad form generally speaking to do it (rebase or change history) to a published branch that more than 1 person is using for any other reason than extreme necessity, such as cleaning up security accidents where someone pushed keys or info they weren’t supposed to. And for exactly that reason, all the opinionated DVCSs that claim to consider history “sacred” actually offer the ability to easily rewrite published history, including Hg and Fossil!

This shows your lack of knowledge and XP with other DVCS and your assumptions there.

> Git’s ability to rewrite local history is pretty important for (1) encouraging a commit-early commit-often workflow where the local repo is a safe space,

No, I can do that with out rebase or cherry pick.

(2) cleaning up your work to make it presentable and semantically organized before sharing/publishing, and

Bad practice. Your history is useful metadata about what happened. I don't want a single commit in your PR. I want to see the reason it took X days.

(3) allowing real-world workflows where people didn’t plan every single feature branch in advance but happened to end up working on multiple things and committing them first. >

That's a nonsense claim.

> A version control system should be, first and foremost, a safety net that simply backs up any work you do without judgement.

Then use Dropbox?

>Personally, I consider the idea that commit history is sacred to be dogmatic and unnecessary.

I think this shows a lack of XP in maintaining older systems.

>I’m open to the idea that it might help prevent a few specific types of accidents here and there, and it might be fair to argue that offering tools to groom the history’s presentation, separately from the log of commit activity, is on average a slightly better idea than having to actually reorganize commits before pushing them. Maybe that didn’t occur to git devs before it was released, or maybe it did and they decided it wasn’t going to help anyone and just add confusion to have two separate timelines. I don’t see any reasons justifying calling git’s design a ‘mistake’, and there seems to be evidence that most people are fine with git, and that for whatever reason the DVCSs that reacted to git in 2005 by immediately trying to fix some of git’s perceived issues didn’t ultimately fix the problem well enough to gain traction.

Yes, history grooming is purely something for a UI to do.

You’ve lost me from the start, this is 100% bad faith argument. This is against HN guidelines too, the mods have confirmed that parroting Dr. Hipp’s hyperbole is not welcome here. The irony is that calling it a “lie” is pure hypocrisy on your part. You already know that rebase wasn’t invented for the purposes of deceiving anyone, and you’re already aware that nobody using git is under the impression that commits won’t get rearranged (rebase is proof of that), nobody is expecting git commit dependencies to represent the historical order events happened in, because that’s not the way git works and not what it was designed to do, which means you are the one lying here. If you don’t know or can’t talk about git’s design in terms of what git designers were actually intending, then Chesterton’s Fence, you don’t get to tear it down.

What’s so sad about this is you and other Fossil followers are stuck on the bogus bad faith argument, lowering yourselves to attacking and name-calling, when a good faith argument exists and is just waiting for you to adopt it. You don’t have to repeat this stupid hyperbole. There are good reasons to consider other DVCS designs. There are ways to talk about and justify and sell what Hg and Fossil do without trying to villainize git and git users. For your own sake, and for the sake of setting a better example for other Fossil fans, try to find the strength to shed yourself of the negativity and explain why other systems are better than git while maintaining the stance that git was a good design for it’s time. If you can’t do that, then seriously, consider the possibility that the thing you’re arguing over actually isn’t better.

It's like using an ORM as an abstraction. Someone could build an ORM that took a hard stance that raw SQL should never, ever be used. Such a tool is less useful than an ORM that allows raw SQL but encourages the use of the ORM's facilities instead.

We've been using Mercurial branches for more than a decade like Git branches. What specific problems did you have with Mercurial branches? I've never used bookmarks with Mercurial.

> I could never figure out how to clean up properly if I made a mistake

Interesting because that's my biggest problem with Git. In Mercurial, it's just about learning the meaning of the distinct terms like "rollback", "revert" and "backout". In Git, you must know the many cryptic variants of "git reset" instead.

> Simpler than a DAG with pointers? Sure.

I don't how Git's DAG different than Mercurial DAG from a user's point of view. In my opinion, Git's mutable by default semantics and staging area adds unnecessary complexity for a beginner. That's what I mean by simpler.

> If I remember correctly you even needed to install some kind of external plugin just to do simple rebasing / branch cleanup.

They're all built-in but opt-in features called "internal extensions". Maybe, you're referring to early versions of Mercurial from 15 years ago or so when they were external.

> Now's the part where you tell me I'm doing it wrong, shouldn't be rebasing etc

I use history editing, MQ, rebase daily. I find them handy. But they can be confusing for beginners, so I also understand why they're disabled by default.

> and the constant claims that it's somehow objectively "better" but misunderstood get really boring.

It's impossible to compare two DVCS's objectively other than performance for certain scenarios. But, as a person who uses both daily, I find Mercurial much easier to use, yes.

Made a mistake doing what? A mistake in your code or a mistake using Mercurial?

> If I remember correctly you even needed to install some kind of external plugin just to do simple rebasing / branch cleanup. Now's the part where you tell me I'm doing it wrong, shouldn't be rebasing etc etc, but I'm just saying, it didn't work for me

I've never understood this impulse to do "branch cleanup". Why are you adding unnecessary work? Is the source repository for tracking a history of changes or is it an art exhibition?

The history is an end product intended to help others (often future me) figure out when and why things changed, preferably in self-contained, well organized steps. Often my first attempt at a change does something in an illogical order, or I make related changes that later end up in a separate merge. In the short term that change in thinking is somewhat interesting. In the long term it only confuses whoever is looking through the history to figure out why something is the way it is.

The stronger version of this completely discards any history when merging a feature, but I often find that to get rid of useful information.

https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

> The Git documentation acknowledges this fact (in so many words) and justifies it by saying "rebasing makes for a cleaner history." I read that sentence as a tacit admission that the Git history display capabilities are weak and need active assistance from the user to keep things manageable. Surely a better approach is to record the complete ancestry of every check-in but then fix the tool to show a "clean" history in those instances where a simplified display is desirable and edifying, but retain the option to show the real, complete, messy history for cases where detail and accuracy are more important.

Points 1 to 4 argue against the idea of rebasing as an alternative to merging. I agree with this to some extent, but in practice I notice that the exact point at which a branch began is rarely important. A very rough heuristic for this is "can it be rebased non-interactively?". This effectively means I like "cherry-pick merges", and it would be cool if Git remembered more about the origins of them. Rebases that do require manual adjustment are far more error-prone than merges, and I try to avoid those.

Point 5 and 6.0 are the primary reason I edit history. I want my history to tell a coherent story, not just in commit messages but also in the changes themselves, and that story often doesn't perfectly match the actual road traveled to get to the end. I don't much value mistakes where I forgot to implement half a change while tired at the end of a long workday, or an ill-considered false start. Where such information is valuable I'll write it down in the commit messages of changes that implement what did end up happening.

That brings me to the other points. I very much agree with 6.1 and beyond. Squashing branches removes a lot of valuable information, and it removes the ability to tell that coherent story. In particular:

- There are often small changes or bug fixes that aren't really part of the set of changes, but that just happen to become most relevant while developing this feature. Depending on the specifics these could be merged separately, and I keep them separate.

- Nuances discovered later in the development of a set of changes tend to offer valuable insight, so I want to keep them separate from the rest.

It would be cool if Git remembered more of the specifics of how the end result was reached, but I'm not sure if I would use it much in practice.

1. Some small commits in preparation for the bigger change, that are also desirable should the rest never end up being merged

2. The big set of changes, either in one big commit or in a handful of smaller, independent commits

3. Some (usually smaller) commits that reflect nuances thought of or discovered after the biggest batch of changes was made

Most of my history cleanup serves to separate part 1 and 2 and to turn part 2 into a set of coherent steps.

Depending on how things go each of these might be merged independently or all at once.

Development is often not self-contained or perfectly organized, so we shouldn't expect this of the change history either.

> In the long term it only confuses whoever is looking through the history to figure out why something is the way it is.

Source control is the wrong tool for this job, that's what comments and tickets are for. Source control can help you retroactively figure out how and sometimes why something evolved in a certain way, like a good archaeological tool, but we don't use crude tools when there are better tools.

I've taken to literally embedding ticket numbers along with comments directly in the code and in commit comments to document exactly why code does what it does. All functional changes are tied to tickets [1], and the tickets contain the full context, and the code comments contain a summary of that rationale. Use the right tool for the job.

[1] where "functional changes" means changes that can affect behaviour, rather than stylistic changes on variable naming or revising comments that have no visible effects.

It won't ever be perfect, but that doesn't mean we shouldn't strive to get as close as possible.

> Source control is the wrong tool for this job, that's what comments and tickets are for.

I agree that code comments play an important part in explaining why something is the way it is. Code comments and commit messages play a different role there, but they overlap and it can be tough to balance. Roughly: commits explain changes and the decisions made to arrive at that set of changes. Comments explain the end result and the decisions relevant to explain that end result.

I disagree that tickets are a better way to convey this information. Embedding references to tickets is not necessarily a bad thing, but the lifetimes of issue trackers and source code history tends to be different, so all relevant information from such references should be in the comments or commit messages.

Agreed. So a linear history doesn't seem of much use if your current code is well documented, so are all of those pushing for linear history just poor at documentation?

> Embedding references to tickets is not necessarily a bad thing, but the lifetimes of issue trackers and source code history tends to be different

This is why Fossil ties the ticket system along with the VCS all in one system. In the end, I think the ticket system is almost as valuable as the source code, and shouldn't be causally tossed out.

The proper solution is to build a better log display tool, not change the log itself.

* Separating out different conceptual changes that are/were reviewed together and

* Transparently cleanup a messy history that starts with a few base commits (corresponding to the conceptual changes) followed by a bunch of fixup commits for issues found by CI and review.

That is the main problem solved by rebasing. I have yet to see even a coherent proposal for what the alternative would look like.

https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

That said, it gets quite close to an interesting idea here:

> Second, if Git remembered the source of cherry-picks in commits, Git users might have a better argument for avoiding rebase, because they’d have an alternative that didn’t lose history.

I like the idea of properly remembering cherry-pick sources in commit metadata. It would be a cool thing to have, and potentially sometimes useful.

But try to really imagine a world where this is how Git worked. How would you solve the two problems I stated in my GP comment? You'd just transform state A of a branch into state B by performing a sequence of cherry-picks. And that's pretty much exactly what git rebase is...

So no, the author's proposal wouldn't eliminate the need for the rebase flow. It would subtly change the result of a rebase in a way that preserves more history. Which may or may not be useful, but I mostly wouldn't mind it.

(Just for your consideration, losing history can be important when you're maintaining a mixture of open and closed source / trade secret branches. You may not care personally, but being pragmatic about such things has certainly helped git.)

I'm sure they understand the use cases quite well, and designed their Fossil VCS to address these faults.

> And that's pretty much exactly what git rebase is...

Except rebase disconnects it from the history where the author's solution does not. A view on a SQL table does not change the underlying data, it just presents it differently. That's the difference between what the author's proposal and yours.

I am very happy when something like this happens. It means performance matters and a performant implementation is rewarded with market share.

This performance is what made git win, even if the “porcelain”, the CLI commands we use, are not as well-designed as the ones in Mercurial.

Hopefully one day we will no longer use any chat client written in Electron. =)

by this you mean technical group think or monoculture?

For me I'd say it's that git doesn't fit my mental model and Mercurial does - it's that mercurial gave me a smaller mental model that (at least back when I used it heavily) allowed me to do what I needed.

Even as a fairly experienced and advanced Git user, Git requires me to keep more state in the head and at, from my point of view, unpredictable times needs me to extend the model. The strange thing is that this is despite having a very simple model at the lowest levels of the system.

    - We will continue to use Bugzilla, moz-phab, Phabricator, and Lando
    - Although we'll be hosting the repository on GitHub, our contribution workflow will remain unchanged and we will not be accepting Pull Requests at this time
    - We're still working through the planning stages, but we're expecting at least six months before the migration begins

As sad as it is, I see Firefox losing ground even on the developer side.

Gitea, Gitlab and Sourcehut are in my opinion very decent alternatives to Github providing the same functionality (if not more) without any ethical downsides.

I moved completely to Sourcehut, and I'm not coming back.

The reliance on email though is a hill I'll die on. In the 90s when spam was less of an issue that would've been great. Now? I don't want to be forced into dealing with fucking email to manage issues. So yeah for my projects (which are quite small) I think SourceHut is a great fit. For a large project like rust or firefox? Not so much.

Going GitHub is just so orthogonal to a mission of "openness".

Github makes money without producing open source software. <rant>Well, that is if you don't count a sluggish electron-based text editor.</rant> Github is not open source, Github Pages is not open source, Github Actions is not open source. Sure, they offer free hosting for open source projects, but that kind of charity creates a hard dependency on Github for many projects, which is not healthy for the ecosystem.

What happens if Github closes? Or stops free offers for open source projects? To make an analogy from another ecosystem, if Mac Donalds started offering free meals to homeless people, that would not solve the problems of poverty and would not contribute to healthier food for the people or a more sane/ecological agriculture. That'd just be charity for their own gain.

Yes, it is. Otherwise, your contribution is not part of the OSS ecosystem.

> github offers free services for OSS developers who otherwise would have to host them themselves

Github offer free services to anyone, OSS or not.

> that's the reason why they got so popular and i think we can all agree on the fact that it's incredibly useful

I think we can all agree it's called a "loss leader". It's not useful whatsoever to those who refuse to further enrich a for-profit company producing proprietary software which considers your own assets to be their proprietary data (see also: Copilot). In fact it makes things more difficult for us because we're locked out of contributing to virtually any OSS project.

I've whined endlessly about how buggy and generally awful the new UI is, but what really drove it home is having to use an old computer with an old browser. Absolutely nothing (not even static text) loads on Github without a modern javascript interpreter.

Github is ready to be put out to pasture.

My understanding (possibly flawed) is that github started by using the current git tooling but that they soon started running into issues because the CLI tools were never meant to scale and never as a web application.

So they wrote their own implementation of git (their own tool that understands git repositories) but did so in a way that's more compatible with the scale and the web-oriented work they do.

So it's not even clear to me how much of the actual code they have running is open source.

It is bad enough that Firefox depends on Google money for survival, I don't see why they should give even more of their freedom away to rely on Microsoft.

The kind of low-effort contributions that you would get from people that will only contribute because you are on Github are not the ones that you need or want anyway.

Plus if they wanted a alternative, Gitlab is so much more pleasant to work with anyway.

If someone had told my 80s/90s Libre/OSS advocate rebel mind how things would pan out, I'd laughed.

Azure accounts for something like 35-40% of all their revenue, and those pesky tenants insisted on installing Linux and running things on their other than Exchange or Microsoft Dynamics.

With Microsoft there's always a catch. ( they're are not alone of course ).

They also try to influence the market. To build lock-in. They’ve never stopped doing that.

We ended up switching to Gitlab because Github-style code reviews are just so much easier to deal with. They hit the spot between "good enough" and "easy to use". Phabricator's bloat made it unbearable

Don't understand moving to Gitlab because of the bloat though. There are lots of lighter weight tools, but Gitlab is the whole kitchen sink and then some. The integrated-ness is part of the package with these tools.

You're totally right: it was years ago, and Gitlab used to not be as bloated at the time. I guess today we'd migrate to Gitea instead.

Not only has it been years since I last have heard of bugzilla, I also really resented it! Moving to a modern infrastructure really improves accessibility for developers. For example, GHC (Haskell Compiler) moved to gitlab a few years ago and while previously it was really hard for me to understand the development process nowdays I can follow pull requests and tickets of features I am interested in without any problem. Previously the system was really complicated and, if I remember correctly, Phabricator, mailing list etc. based. Off putting as a newcomer.

Also consider that Mozilla’s bugzilla contains quarter of a century worth of tickets. There’s no way it can be moved to GitHub (or wherever) without loss of data.

I understand why Mozilla can't/won't go that route, but seeing organizations attempt to duct-tape solution together with Bugzilla, Phabricator, Jenkins and whatnot makes you appreciate what Atlassian has done with Jira, Bamboo and Bitbucket (even if Bamboo and Bitbucket aren't exactly industry leading). I suppose that Phabricator was intended to be a Jira/Bitbucket/Gerrit alternative of sorts, but just failed to get the required traction to survive.

It's not just open source projects, way to many companies are attempting to knit something together and they end up with this unholy mess of systems that sort of communicate, but not really. The saving grace is actually Git, because everything works with Git.

Git was suposed to be a decentralized, peer-to-peer way of managing software using standard open-source tools, and Github is the exact opposite.

On the other hand, they're moving from open source tool to a closed ecosystem and depends on microsoft. Very sad.

1: I don't have any hard data for this, but I don't think it's overly controversial.

Although I suppose you could argue the cause is the choice of keeping so much in a single repo (I certainly would).

it almost feels like there should be some intermediate target language - like the syntax server that syntax highlighters target (forget the name)

not aure how but it feels doable

It's not vague, I immediately know what the article is talking about. I can accurately judge whether I am interested in further reading just from a passing glance.

This is how headlines should be written.

Choosing git not only means they need to do a lot of work migrating from mercurial to git, but git is arguably a worse SCM than mercurial, or at the very least not an order of magnitude better to justify a switch.

Personally, I chose Mercurial to start with, because I liked the Windows tooling available and it felt a lot more like Subversion, which is what I used previously.

However, Git won the mindshare war in the end, so I moved over to that.

Ahhhh, thanks for brining back those memories.

You're not thinking about BitBucket are you? I thought Github was always git only?

What I mean was that it wasn't like Bitbucket where you chose whether you wanted git or hg for starting your project.

I think Google Code provide both from the early day (along with Subversion), and maybe also SourceForge.

That was over a decade ago, however; I'm actually pretty surprised it took Mozilla so long to switch.

I'm a happy git user but I'm really curious about losing good ideas from other tools due to mindshare.

However the killer feature of Git is the ecosystem. I was always having to do lots of custom work to get Mercurial to work with CI providers, whereas Git just worked and had first class support. It was clear after a while that our team would always be outsiders if we continued down that path, and there wasn't enough of a compelling reason to stay with Mercurial.

hg has (had?) a sane CLI that blows (blew?) git out of the water.

I like the power of git, but it either needs external tooling to prevent people from shooting the team in the foot, or relatively thorough study by everyone using it.

In practice, for git, most of the time you need some software to protect people from messing up repositories and history (gitlab, github, etc, which honestly you're gonna use anyway), while hg on its own protects you out of the box from most mistakes.

All FAANGs I'm familiar with use git, but there are some serious handrails and straps on what you can do. On smaller companies I had so many arguments about rebasing public branches that it's not even funny.

For a while I had in the back of my head to create a hg clone that was a wrapper around git, in a way that it'd allow hg-style workflows and protections, while having a faster and more well-known "backend".

If git was an equivalent modern appliance, it would be against the Geneva convention.

I give Git this, it's a bit faster.

Honestly, the biggest problem with git is sane environment for merge conflicts and that is out of scope of git CLI. In most cases, imposing rule for small PRs/feature branches will solve it.

git add, git commit, git log, git blame, git push, git rebase -i --onto. That is 95+% of what developers use (maybe an option here or there, like -m or --amend). Merges are done on CI after it passes.

There are a lot of arcane parts and switches. git-send-email is likely used a lot on kernel development, but very rarely in the rest of the world.

> I've got 10 years in it and it still bites me in the ass.

Can you give some examples? I had some problems in the beginnings, but it was because i tried to be "smart".

After I embraced KISS, everything works nicely. As long as I keep "public" branches protected, any splash zone is very small and at worst, just redo it(synergy with small PRs).

What do you mean? Hg and Fossil don’t capture what “actually happened” either, they don’t show you stuff you typed and deleted before committing. They don’t save the compile errors you had or what you tested and changed. They don’t save what you said to your coworkers about their code because they were afraid to set their changes in stone or make a mess. They don’t prevent anyone from putting things into the commit log in a different order than they “actually happened”, and they can’t: these are systems that record only what you tell them. What problem, exactly, does trying to capture ‘what actually happened’ help solve?

I don’t understand this obsession with what “actually happened”, as if there’s something critical about auditing keystrokes, as if the working code and the state of the tree are secondary. No DVCS can prevent someone from designing what their commit history looks like. In the mean time, the idea that you shouldn’t be able to edit or change anything locally before showing it to other people seems like a negative force against the basic safety net that a version control system needs to provide. (And no existing DVCS actually prevents rewriting history anyway, they just claim to have preferences and they offer commands to rewrite history that have other names and say honor system, you shouldn’t use them very often.)

> revising it to make it look “clean” doesn’t actually help with anything.

Hehehe you’ve never had to look at the history then, I assume? You’ve never had to bisect? You don’t care if people interleave different topics in their branches, or make lots of 1-line fixup commits all over the place? You don’t care about how long it takes to find out who changed something, or whether you have to sift through a mountain of garbage to find it?

Don’t the DVCSs that have the ‘history is sacred’ dogma also have tools to make presenting and viewing history less noisy than the so-called ‘what actually happened’ commit log? Doesn’t that prove that a clean view of history does help, and is something a lot of people want?

They show you what you actually committed and don't allow you to do stupid things that might corrupt your repository, which is what matters.

> I don’t understand this obsession with what “actually happened”, as if there’s something critical about auditing keystrokes, as if the working code and the state of the tree are secondary.

"Working code" and important milestones in the state of the tree are tracked by tags, bookmarks and other features depending on what source control system you use. The state of the tree at every single commit point is an irrelevant detail.

> No DVCS can prevent someone from designing what their commit history looks like.

Correct, and they shouldn't encourage you to waste your time trying to do so, and so shouldn't make it easy either.

> Hehehe you’ve never had to look at the history then, I assume? You’ve never had to bisect?

I've been doing it for over 20 years, first with subversion, then Mercurial. Never had any issues figuring out what was going on. Taking a few extra minutes here and there to scan through such changes is nothing compared to trying to fixing a repository corruption, which is something I recently had to deal with.

Everything you describe can be handled by 1) a better commit log history tool and more importantly, 2) better development practices that requires adding proper comments and tickets to code and commits that describe context and rationale for changes. Opening up history to revisions is a sledgehammer trying to solve a bunch of distinct problems that require better solutions.

> Doesn’t that prove that a clean view of history does help, and is something a lot of people want?

Of course it helps, sometimes. As I've described above, that doesn't mean you should introduce a sledgehammer for the occasional pain point that can be addressed by other, arguably better means.

Who cares what you actually committed on a per-commit basis, especially when fixing things that were mistakes in the first commit, and would have been committed as part of the first commit with more planning and/or no innocuous accidents? Who needs to preserve the already arbitrary order of commit commands, and why? I’ve never heard a compelling and real-world reason to need this, nor any popular workflow that this idea establishes or improves.

And what repo corruption are you talking about? I don’t know about you, but one thing people espousing this ‘what actually happened’ philosophy and trying to trash-talk git tend to deliberately overlook is that git commit histories are immutable, and rebase only produces a new commit lineage, with an in-tact backup of the previous lineage surviving anything you do. It’s not possible for the history to be irrecoverably corrupted, unless you’re unfairly including bugs or hardware failures. Recovering from rebase mistakes is simply a matter of learning where the undo knobs are, and ultimately they are pretty easy to use, it’s no more work and no different outcome than learning how to groom the presentation history of Hg or other systems.

Follow-up fixes reveal important nuance and implicit assumptions that shouldn't be erased.

As for your other claims of "simply" and "easy", you need only peruse this thread that covers plenty of rebase stories losing entire commit histories and requiring redoes of weeks worth of work to see either it is neither easy or simple.

Edit: See also this point by point breakdown: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

BTW I have a ton of respect for SQLite and Dr. Hipp’s work. I love the way he has talked about testing. Nonetheless, I’m very much not a fan of their trash-talking of git that intentionally ignores the context, guidance, and real-world usage of rebase. The irony of them saying that git rebase is “dishonest” is that they themselves are being intentionally dishonest about how they talk about git, and I find it very off-putting and hypocritical, to be as polite as possible.

That’s definitely not always true. In my experience that’s a small minority of cases, and when it happens, I keep the important nuance commits and don’t squash them. Nobody is forcing you to squash, it’s an option for the (many) fix up commits that were pure accidental oversight and have no nuance that needs to be preserved.

I’ve seen lots of people claim they lost work, because they freaked out or gave up without slowing down to think carefully. The reason is because they didn’t learn how git actually works, and never learned the undo buttons. I’m well aware that git’s CLI is intimidating and unintuitive, but one thing it does not do is corrupt your repo for you. That’s effectively a blaming excuse for not having learned how it works.

Edit: I work for Mozilla, although I didn't in 2006 when I think the decision was made.

But Rails was a very early Github user, and the big Rails usage upswing coincided with that and helped drive it. I was a Python and PHP dev at the time, and that other stuff mostly predated Github and was scattered across all kinds of places. Whereas Rails and Github both kicked off about the same time, and practically no Rails devs or libraries used anything else.

It was that fast growth and hype combined with the network effects of Github that drove git usage rather than what Linux used. The Linux contribution workflow was also pretty alien to Github focused webdevs.

That's how Sourceforge rose to become so dominant it appeared unstoppable, and how Docker became immensely popular so quickly.

Bitbucket also had free Mercurial hosting in 2009. I think it was 1 private repo in the free plan and it was later expanded to unlimited free repos with max 5 users around 2011.

So Linux was always going to be git; and I think things flowed from there.

There wasn't a similar offering for Mercurial, in part I think because of the fundamentally different way Git and Mercurial treated (treats?) branches. In Mercurial branches were permanent, so a PR-like flow would leave a lot of stale branches around.

Mercurial also didn't support rewriting history as a core philosophical choice.

It was introduced via a plugin but that meant each dev had to enable it to use it. AFAIK it has been moved into the core, but I think too late.

At least as a primarily Mercurial user at the time, I feel Git didn't really outcompete Mercurial until Github and PRs came along. It just allowed for much smoother cooperation.

But those are big company problems and I suspect the caveats, tradeoffs and solutions matter a lot less for the 99 % of other VCS users.

But Git definitely won the war, and Mercurial has been disappearing little by little.

Might not have much to do with git vs Mercurial technical merits.

Still, with Linux behind it, Git won the DVCS wars. Mercurial became an also-ran and now almost nobody uses it.

Too bad.

We'll need something new and innovative to come out and rid us of constant blogs explaining how Git works because it's too hard to understand how to make it do the things you want it to do.

I've been using Git for about 7 years now (5 exclusively) and I know how to use it, but I still have to look things up occasionally because its UI is trash and non-obvious. I didn't have that problem with Mercurial. There, I knew the verb and the built-in help was sufficient to get me where I wanted to go.

Worse is better wins again.

Just try to clone Mercurial repo (Firefox) and roll back in history to specific commit. Let me tell you beforehand - it is (at least used to be) impossible. What you could do is to "clone it again" up to specified point. You have to do it somewhere else on a filesystem just to needlessly spoil disk space and you end up having the same sources at least twice. When I asked why I got handwaving arguments about code history being sacred, which is of course nonsense. If it was so... in Git I'd make another branch and rewind to commit I care about without wasting another 25gigs of disk. How can be this achieved in mercurial these days (without waste)? Back in days I wanted to do some work specifically on Firefox, and those steps were the only I could come up with after a lot of searching and asking questions, and because of Mercurial I gave up, to me it felt like it was a high entry barrier on purpose.

So, no my friend, a lot better wins time.

hg clone ssh://example.com/repo

cd repo

hg update -r $SOME_COMMIT_HASH_OR_ID

```

Unless you mean you want to delete history back to a certain point, in which case it's only slightly more complicated.

Ten years ago, when I had started to use git after having used both Subversion and Mercurial, I noticed one thing.

Git was FAST.

On repositories of the same size, git was blowing Mercurial out of the water and running circles around it, that's how fast it was.

It was FAST and it fucking got out of my way and let me work.

I don't know the inner workings of either and academic advantages of Mercurial, but I know for a fact it had been a dog and its move to Python 3 had been disastrous. So whichever technical or UX advantages Mercurial might have, I simply don't care anymore.

Then git-svn was born, and you could branch instantly. This was such an obvious improvement that all future repos moved to git.

Merging in SVN on the other hand…

Read about Jujutsu awhile back.

https://news.ycombinator.com/item?id=30398662

I am quite surprised that no open source variant has been created yet (that I'm aware of).

But not for the reasons that correlate, such as education, tooling.

https://soberbuildengineer.com/blog/2007/04/version-control-...

https://soberbuildengineer.com/blog/2006/11/version-control-...

Unfortunately, GitHub got VC funding and caused network effects to kick in.

Git came along with GitHub as a parasite much like C came along as a parasite with Unix.

Actually, it scales well with large codebases, but the monorepo mental model pushed by FB/Google doesn't match the git workflow model. Git repo design is for a concrete entity: a single tool, binary, service, kernel, whatever. When you start bashing in multiple unrelated projects where you try to have various per-project versioning schemas, it becomes a mess.

I don't really see a benefit of having all code of an org in a single repo. Single product, sure. But whole company? Why. Not to mention, these are serious outliers.

From security standpoint, it doesn't seem great, from practical side, it's not great (bandwidth cost ect).

It's more complex comparing with git naked graph. Contains more domain entities. But it could be more convenient for starters and SVN users.

Also looks like they're still planning on using existing review tools:

> We will continue to use Bugzilla, moz-phab, Phabricator, and Lando... Although we'll be hosting the repository on GitHub, our contribution workflow will remain unchanged and we will not be accepting Pull Requests at this time

Hosting it elsewhere means people are less likely to find it in the first place.

Using a different VCS means people are less likely to pick it up. Instead of starting on their contribution they have to install and learn new tooling that is irrelevant to the project itself.

Emacs is a pretty good example of this. There are plenty of people who would be interested in making improvements to the project but a much smaller proportion are willing to engage with the email-based process that's required to do so.

The crux of the issue is that the social element of an approach is just as important as the technical merit. A technically superior solution will quickly languish if no one can bear to work on it.

But Firefox is a well-known software and, at the same time, a very complex one. I don't think that somebody who struggles figuring out how to contribute via, e.g., Gitlab, will be able to contribute anything useful to the project.

People only have so much time and even insignificant barriers reduce participation.

The Emacs example is a bit more involved but still demonstrates this. There's nothing particularly difficult about submitting patches by email but the thought of doing so does put people off. The same goes for the copyright assignment, not difficult at all but reduces participation.

> For a long time Firefox Desktop development has supported both Mercurial and Git users. This dual SCM requirement places a significant burden on teams which are already stretched thin in parts. We have made the decision to move Firefox development to Git.

You're implying that Microsoft would find some reason to shut the project page down. First, I don't think they would.

Second firefox is entirely open source, so worrying about trade secrets is no concern. Next, code is in git, so the project could be spun up elsewhere, even if import and export of issues and the association of user accounts would be a one-time hurdle.

That Microsoft will disable the repo and prevent updates?

Or that they’ll read the open source code published to the repo?

This is not what open source is supposed to mean.