You read those stats wrong. Those are lifetime odds. Not odds per event. Otherwise, over the course of a year, everyone who commuted would likely be dead.

> If your team is avoiding a tool with a 1 in 16,000 chance of failure then they'd probably also want to avoid flying (1 in 20,000 chance of death by failure), large bodies of water (1 in 8,942) and run terrified from cars (1 in 100) (source: http://www.livescience.com/3780-odds-dying.html.

That's not how probability works. That assumes a uniform distribution, but it's not uniform at all: if you run the affected versions of git and run a particular sequence of commands, you will hit this problem every time. Assuming that the Linux community's workflow doesn't change that often, the Linux devs would likely never have hit this because they don't run that sequence commands. Because it's not actually random, we do have control over it, and your suggestion that we all just "get over" the fact that an important tool lost user data seems pretty cavalier.

Actually though, there was a 0% chance of this happening to anyone who uses git properly and commits before merging, and a 100% chance of it happening to this guy.

If this is how you properly use Git then why do they allow the improper way to do so? This seems like broken UX if you allow people to do something that will 100% cause catastrophy -- unless there is virtually no way to design it otherwise (but it's obvious that this is not the case with Git).

Because you should have read the man pages.

Right?

Right?

No, of course not, and your point is obviously clear. "Blame the user" is still in vogue in some circles, though.

In this case the git pull man page is relatively clear that:

"If any of the remote changes overlap with local uncommitted changes, the merge will be automatically cancelled and the work tree untouched"

... which git failed to do properly. So the git-pull man page is clear that it won't clobber your uncommitted changes. Except in the (buggy) case when it will.

To be completely honest it's because git is made by and for hackers. It gives you a lot of rope. If you choose to "git reset --hard" after doing some very important work and not committing, hey, guess what, git won't stop you. Neither will "rm -rf".

Learned that lesson the hard way ... well, what I had meant was git reset --soft, what I had typed while tired was git reset --hard.

Either way it gave me a chance to re-factor the code, and do it better which ultimately ended up being MUCH better anyway.

This reminds me so much of the UNIX Hater's Handbook, which argues that this attitude ("it's just a rite of passage", "it is better now anyway") is a result of growing up in a world where the design errors of UNIX are seen as features. I don't know yet, but it is an inspiring read nonetheless: http://www.simson.net/ref/ugh.pdf

I've read the UNIX Hater's Handbook a long time ago. I have a hard copy stored in a box somewhere.

I don't quite understand what point you are trying to make though. Ultimately the code loss was my fault, however it ended up much better for the source code I was working on because I had time to think about what had to be done and how I should do it, ultimately leading to less code that ran faster and was much better organised.

When you rebase in a dirty tree, it won't let you. I think merge should be the same. I manage a manage a large number of products, and from time to time I rebase and find unexpectedly there are changes in my working tree. If I merged, I'd not have seen it.

I really wish merge, by default, was disallowed on a dirty tree. Yeah, it'd be fine if there was a command line argument to override this behavior.

It was a bug. It was broken UX. Everyone agrees with that. And it has been fixed.

But the reason it went unnoticed for (horror of horrors) 2 minor releases, was that it only results from an unorthodox (although supported) usage practice.