Mercurial has always been better than Git on Windows.

Those dubious features are so relevant to daily work that I didn't even knew they existed.

Git main target is Linux. Obviously. Performance on the truly secondary platform was not relevant and it is mostly caused by slow lstat call.

Instead Mercurial uses additional cache file which instead is slower on Linux with big repos. But happens to be faster in Windows.

And the octopus merge is used by kernel maintainers sometimes if not quite a lot. That feature is impossible to add in Mercurial as it does not allow more than two commit parents.

Which reinforces the position that git should have stayed a Linux kernel specific DVCS, as the Bitkeeper replacement it is, instead of forcing its use cases on the rest of us.

>Which reinforces the position that git should have stayed a Linux kernel specific DVCS

No it doesn't? People use octopus merges all the time, every single day.

Well, I only get blank stares when I mention octopus merges around here.

...as I get stares (okay, mostly of fear) if I point out that we need a branch in my workplace. What you can/can't do (sanely) with your tool shapes how you think about its problem space.

To emphasize that even more: Try to explain the concept of an ML-style sum type (i.e. a discriminated union in F#) to someone who only knows languages with C++-based type systems. You'll have a hard time to even explain why this is a good idea, because they will try to map it to the features they know (i.e. enums and/or inheritance hierarchies), and fail to get the upsides.

Easy, is is called std::variant, available since C++17.

Yeah, I guess. Except that std::variant is basically a glorified C union with all the drawbacks that entails.

But git didn't force its use on anybody, lol. If you need a scapegoat, try GitHub!