[acdha]

Mercurial also missed the window on performance and safety. If you started using it around 2009 or so, Hg was notably slower for daily use and a lot of people recommended using extensions to match Git features but those extensions were not stable (Hg and RCS are the only VCSes I’ve seen require data to be recovered from a backup due to normal usage).

There’s a meme that Git is hard to use but I think it’s conflating the challenges of getting used to version control at all, distributed version control, and any specific tool. I watched a number of developers do that and it was about as much work to go from SVN to either Git or Mercurial, and if they learned the other DVCS it was always easier since they were mapping concepts rather than learning them for the first time. The marginal returns on productivity weren’t worth switching in most cases so it tended to come down to Git being so much faster and, as network effects kicked in, easier to host.

[compiler-guy]

> There’s a meme that Git is hard to use but I think it’s conflating the challenges of getting used to version control at all, distributed version control, and any specific tool

That may be the case for some people, but far from all. Many people who started with cvs or even rcs and have moved on to the newer things as they have appeared still find got annoying and unintuitive. Especially compared to Mercurial.

You use it, because it is now the standard, but you are also very aware of how much cleaner and easier other systems have been.

[acdha]

My experience was comparing multople people who started with Mercurial and later learned Git, and had basically all of what people term “Git problems” with Hg because the hard part was thinking about distributed version control.

I’m not saying Git is perfect but simply that it’s hard to separate the difficulties from learning new concepts and working styles from the tool.

[mrweasel]

> Hg was notably slower for daily use

There was an interview with Linus Torvalds at some point where he points out that Mercurial was one of the tools he tried using to replace Bitkeeper, but found it to be much to slow. Has he tells it in the interview he later learned that the slowness he experienced was due to a bug in Mercurial and had that not been there, git might never have happened.

If that's true it a little sad, but I also wonder if many of us might still be on SVN, Perforce or whatever. Git, by being a product of Linus brought a lot of focus on Git. Bitkeeper never got the same attention, that was a commercial product, but being used for kernel development didn't see to promote it as much as I'd expect.

[HelloNurse]

Bitkeeper was more or less like Subversion, fast, expensive and slightly complicated; you seem to overestimate the relevance and influence of Linux kernel use for the average corporate decision maker who doesn't care about Linux, doesn't care about distributed VC, doesn't care about performance (because it only affects peons), doesn't like to spend money and doesn't like bleeding edge tools.

[fragmede]

We'll never know. But git being used to manage the Linux Kernel did a lot for its asendency. if Mercurial had been the choice, maybe we'd all be on Hghub instead of Github. Bitkeeper's proprietary status is what dampened enthusiasm there.

[oarsinsync]

> There’s a meme that Git is hard to use but I think it’s conflating the challenges of getting used to version control at all, distributed version control, and any specific tool.

Anecdote follows!

I originally started with cvs, and then later, svn. I struggled when git came along, the workflow felt super cumbersome and I kept tripping over the 3 stage process (working directory, staged for commit, and committed), compared to the 2 stage process for already-tracked files in cvs and svn.

After several years, I still never got used to it, and kept having to google when I’d run into random weird issues, having accidentally gotten my repo into a state that had strayed from the basic happy path. Then I started using hg at work, and life got a whole lot easier.

I still haven’t migrated my personal repos off git into hg, mostly because I haven’t (looked for, or) found an hg equivalent of gitea that I can self host, but from my personal experience, day to day usage of git is way harder than day to day usage of hg.

Then again, it helps that I learned hg on the company dime, instead of on my own time.

[pravus]

> There’s a meme that Git is hard to use but I think it’s conflating the challenges of getting used to version control at all

No. I had used CVS, SVN, SVK, Bazaar, and Mercurial for years before I switched to Git. I can generally explain the internals of all of these tools (a DAG) to someone in simple terms in minutes. Overlaying that onto the commands becomes easy.

What Git does is take that concept and wrap it in the worst possible workflow UI. The people that immediately grafted onto the Git community cheered this on for some reason very early and then recanted by saying that you are really supposed to build "porcelain" for Git since it was meant to be a rough tool.

To this day all I see are articles about people's confusions and conniptions over simple things that Git does incorrectly because it's UI is horrible. Most can't even get to the point where they understand the DAG. Even though I know what is supposed to happen it's hard for me to fumble around with simple commands because the naming is inconsistent and I have to research to find solutions. This was rarely an issue with Mercurial and when I talk to people that have used both they seem to share that sentiment.

Git is the PHP of version control. Widely used and very popular but has a lot of architectural problems that make it a total mess.

[pfranz]

> I watched a number of developers do that and it was about as much work to go from SVN to either Git or Mercurial, and if they learned the other DVCS it was always easier since they were mapping concepts rather than learning them for the first time.

We recently adopted a tool that uses Perforce as a backend. It's been interesting to try and describe centralized version control to younger engineers who have only used a dcvs like git.

[chx]

That's not a meme, many git commands have switches which make them behave wildly differently creating massive confusion.

[acdha]

Sure, but most of those are things you rarely need and it’s not like Mercurial was an AI which always knew what you meant - anyone who ever tried to explain merge-queues to someone else knows that some concepts are just harder than others.

[chx]

No need for hard concepts.

I am talking of things like "opsie, I don't want to commit this yet" (git reset) and "destroy all my work" (git reset --hard) being a command line switch apart. That's just wrong. That's so wrong I keep git reset --hard safety net around, in fact. https://gist.github.com/chx/85db0ebed1e02ab14b1a65b6024dea29

[acdha]

Kind of like how “hg update” becomes “destroy all my work” with -C? At some point you do need to learn what things to be careful about. Git’s reflog will avoid most forms of data loss but uncommitted/staged changes are a harder problem than it might seem.

[mkesper]

Newer versions have improved greatly in that regard, but sure you still find too many tutorials etc. using git checkout for everything.

[guenthert]

> There’s a meme that Git is hard to use but I think it’s conflating the challenges of getting used to version control at all

Not sure about that. Git certainly doesn't make it easier by idiosyncratic use of terms and behavior. Why does 'pull' imply 'checkout'?

[CRConrad]

Why should the word "checkout" imply anything particular? (Except leaving and paying for your hotel room?)

[meindnoch]

>Why does 'pull' imply 'checkout'?

???

It doesn't.

[guenthert]

It sadly clobbers your working tree. Not calling that checkout doesn't make it any better. Nothing other than checkout ought to change the working tree -- is that too much to ask?

[glandium]

There are plenty other commands that change the working tree. rebase, cherry-pick, revert, merge, etc. Are you suggesting that all these should be done by checkout?

pull is fetch + rebase or merge. You can use fetch instead of pull if you prefer. Or `git remote update`, for that matter.

[acdha]

How does it clobber your working tree? You’ll get an error if there are any conflicts.

[guenthert]

Yes, sorry, that was poor writing style. Git does indeed warn you that it would clobber your working tree and suggests that you do it in its behalf (the stash/pop dance).

Why is the user exposed to that? If git needs those files checked out for the merge, does it really have to be in the working tree? Why not in a hidden, ephemeral subdirectory? Leave my working tree alone, I say!

[guenthert]

> Hg and RCS are the only VCSes I’ve seen require data to be recovered from a backup due to normal usage.

Count yourself lucky then. Git was well known for losing data, so much, that it was featured at xkcd [1]. Well, perhaps not the tool itself, but it's user interface was (more than it is now perhaps) so awkward that users often got it wrong. If you don't make that back-up, you might not even know how much you've lost.

[1] https://xkcd.com/1597/

[acdha]

That’s not really what that xkcd is about but that was kind of my point: it’s a long-running joke but it’s not really true – in reality Git makes it really hard to lose data, and most of the time when people say they lost data what they really meant was that they had a sloppy merge and needed help using reflog to retry it.

I’ve worked in modest sized teams within a larger organization (roughly a hundred developers) and have often been the person people ask for help when something goes wrong; most of our teams went from CVS / Source Safe to Subversion, and then Mercurial to Git, and the big step was really the switch to a distributed system - moving from Hg was largely a non-issue (things got faster, we liked GitLab more for other reasons). The only time Hg lost data was back in the era when rebase was an extension, so it wasn’t the core system’s fault but it was a source of friction.