Unity, Bazaar, Mir, Upstart, Snap, etc.
All of them had existing well established projects they attempted to uproot for no purpose other than Canonical wanted more control but they can't actually operate or maintain that control.
It would have just been better to continue doing the desktop specific things and let the Plasma Mobile enthusiasts make those changes.
Even to this day there is a complex and archaic process of using Launchpad where git is tacked on because they stuck with Bazaar for so long.
Bazaar and Git were created around the exact same time.
Unity was abandoned after a failed attempt to circumvent Gnome 3. I was actually involved with the development of Compiz and they hired Sam to work on Unity, as he was one of the masterminds behind Compiz, but again they just didn't have the vision or execution to make it work.
If I ever go back to GNU/Linux full time, GNOME certainly won't be it.
Things have improved, but the overall Gnome Foundation attitude hasn't improved. They are still very stubborn and remove basic features. This seemed to start when they did their infamous "focus groups" where they claim users can't understand basic things.
I get the desire to provide a cohesive experience, but I think you can do that while also giving people control.
KDE is shaping up to be much better and it's likely because Valve is providing commercial support and exposing it to a larger audience.
Cosmic is the new kid backed by system76 and its pretty nice too and may rescue Gnome in some ways in due time.
What?
Bzr predates git (by a few days but still). Launchpad predated GitHub by a lot. canonical just played those cards horribly and lost.
You are mistaken here. Bazaar, Mercurial, and Git appeared at about the same time, and I think Bazaar was released first.
IIRC, Bazaar tried to distinguish itself by handling renames better than other version control systems. In practice, this turned out not to be very important to most people.
(Tangent: It wasn't clear at the time whether Mercurial or Git was the better pick. Their internal design was very similar. Mercurial offered a more pleasant user interface, superior cross-platform support, and a third advantage that I'm forgetting at the moment. Git had unbeatable author recognition. Eventually, Git's improved Windows support and the arrival of GitHub sealed its victory in the popularity contest. But all of that came to pass well after Bazaar was released.)
Named branches vs bookmarks in hg just means bike shedding about branching strategy. Bookmarks ultimately work more like lightweight git style branches, but they came later, and originally couldn't even be shared (literally just local bookmarks). Named branches on the other hand permanently accumulate as part of the repository history.
Git came out with 1 cohesive branch design from day 1.
Back when I was testing bookmarks were available, but Bitbucket was pretty much the only forge that supported Mercurial and their tooling didn't support bookmarks, so that made them a non-starter for many users.
When these DVCS appeared, Git's branch design departed from what "branch" meant practically everywhere else. That added to its already significant learning curve, creating more friction for people trying (or being asked) to adopt it.
Meanwhile, Mercurial's "branch" was closer to well-established norms. This was one of several factors that made it the easier of the two to learn, which was was important when already asking people to uproot from their familiar centralized systems and learn the ins and outs of distributed version control. I suspect it also made repository migrations more straightforward, avoiding the impedance mismatch presented by Git's branches.
You seem to be say it like it's a good thing?
Can't wait for that thing to explode and die.
Lying to users and turning apt install commands into shims for a barely functional replacement was disrespectful. Flatpak was and still is better, but even then if I say I want a system package you give me a system package. If you have infrastructural reasons why you cannot continue to provide that package then remove it, Debian based systems have many ways to provide such things.
Canonical did it because they wanted to boost Snap usage and if failed while sending a clear message they don't respect their user base.