Hacker News Reader

Comment by jvm | Hacker News Reader

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.

View on HN

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?

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.

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.

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.

Reply on news.ycombinator.com