[omcnoe]

Lightweight branch model of git mapped so much better to the way that actual development processes of medium to large projects really work(ed).

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.

[foresto]

That's a fair criticism for some workflows, and I like the lightweight model, but we should keep in mind the context of the time:

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.

[nottorp]

I work on a mercurial hosted project right now. What ticks me off is all those unnamed heads you need to handle every time you pull other people's changes. Yes they're more flexible. Most of the time that just means extra operations for no good reason.

[jurip]

Yeah, agreed. I liked the idea of Mercurial branches better than git's — in principle I prefer more rather than less metadata in history — but they genuinely had a scaling problem. I can't recall the numbers, this being more than a decade ago, but I tested with a realistic number of branches for a team of developers using short-lived branches for a while and you could easily see Mercurial slowing down.

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.

[usrnm]

That is very different from my experience with git. I know that the kernel uses branches a lot, but that's probably because of git's history with the project. At every company I worked git is used exactly the same way as CVS or SVN was used many years ago: you make some local changes, you push these local changes to the central store, you forget about it. Branches make local switching between tasks easier, but apart from that nobody cares about branches and they're definitely not treated as an important part of the repo. In fact, they're usually deleted immediately after the change is merged.

[omcnoe]

I think you have it swapped around. This is exactly the kind of workflow that git provided better support for - lightweight branches, not integral part of master history, deleted after merge.