> Git won not because it was that much better than the others. It won because the Linux kernel uses it.
This is a pretty silly assertion to make. You're actively ignoring the SCM's that were chosen by far larger org's. Git took the dev world by storm because it was better. Not because an open source OS used it. Other SCM's had years worth of developer training and interaction with their systems and STILL lost. Years worth of sales connections, demos, networking, you name it and STILL lost.
>They are also losing work because git makes it easy to shoot yourself in the foot
Most people can get the quickie commands down pretty fast, and as long as there are no complaints or errors, it's all OK. But as soon as you need something that takes several steps, your average git user falls apart. Rebases are the most common example. If you don't block force commits from the get-go on a project used by more than two devs, you'll learn that you need to do that pretty quick.
Exactly. Many users get confused and a quick look at the man page shows them a magic --force command that seems to do what they want. Not to mention that we sometimes encourage the use of --force sometimes when we are doing pull requests since we want them to push a squash of all the different commits. It's like a tragedy of the commons playing out in multiple dev teams the world over and it didn't have to be that way. The problem is no one took the time to devote some UX to the git command line until it was too late.
Everyone of these is an example of the git UI/UX confusing you about what is happening. Reflog allows you to recover if you know about it but if you don't you will feel betrayed by the tooling. Blaming the developers for not knowing what Git was going to do is ignoring git's bad ui/ux decisions. Mercurial for instance doesn't have this problem. In fact it tells you whenever you do something that might lose data that it made a backup and where it put the backup at. Everything the developer needs to know right there after they accidentally shot themselves in the foot trying to do their job.
Other SCM's had years worth of developer training and interaction with their systems and STILL lost. Years of worth sales connections, demos, networking, you name it and STILL lost.
You are comparing Git to high cost options like Perforce which lost because they were expensive and OpenSource doesn't like expensive proprietary solutions in a field where OpenSource rules. I'm talking about solutions like mercurial which have a similar underlying model and a better user experience out of the gate. Git beat hg not because it was better architecturally. They have the same underlying datamodel. It won because the linux kernel used it and that gave it the necessary cachet and authority by association. This is not bad git is worlds better than perforce or cvs or svn in many ways. I'd rather use git than most of those in most situations. But I also would rather use hg than git any day because it's the same datamodel with a ui that doesn't mislead me.
>Everyone of these is an example of the git UI/UX confusing you about what is happening.
Um, I don't see it. Your first 2 links are the same question. All "3" examples basically give you a single command to run to get your work back. What's confusing?
> Mercurial for instance doesn't have this problem.
WHAT? Mercurial actively changes the underlying data objects it stores and there is NO WAY to get them back. Rollbacks actively delete content and you CAN'T restore them, shuffle them around, or anything like that. You do have the Journal extension but it's not apart of the core product. And people definitely haven't had problems with extensions before ;). See: https://book.mercurial-scm.org/read/undo.html
>In fact it tells you whenever you do something that might lose data that it made a backup and where it put the backup at.
So does git. Every operation that Mercurial gives you a warning about git does as well. Even better, git still gives you a way out even if you do the thing you shouldn't have done. It warns you in the prompt, it warns you with comments in the text editor of your choice that pops up for input.
Is there some operation you can give an example of that git lets you do that Mecurial somehow magically prevents or gives you a way out of?
>You are comparing Git to high cost options like Perforce
And what about the other opensource SCM's that lost?
>They have the same underlying datamodel.
They do not.
>I'm talking about solutions like mercurial which have a similar underlying model and a better user experience out of the gate.
It definitely does not. Not sure what you want but I'll take practical solutions like git being able to handle partial checkouts, branches, and blames over a nice gui. Git may have inconsistent command flags but it still does what you need it to.
>use hg than git any day because it's the same datamodel
This is a pretty silly assertion to make. You're actively ignoring the SCM's that were chosen by far larger org's. Git took the dev world by storm because it was better. Not because an open source OS used it. Other SCM's had years worth of developer training and interaction with their systems and STILL lost. Years worth of sales connections, demos, networking, you name it and STILL lost.
>They are also losing work because git makes it easy to shoot yourself in the foot
Example?