3 ms·

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 g

by jvm 15y ago

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.

kenjackson 15y ago
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).
- eropple 15y ago
  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.
  - bennoleslie 15y ago
    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"
    - kelnos 15y ago
      ... 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.
- davvid 15y ago
  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".
  - X-Istence 15y ago
    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.
    - deleted 15y ago
      [deleted]
    - rogerbraun 15y ago
      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 http://www.simson.net/ref/ugh.pdf
      - X-Istence 15y ago
        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.
- jvm 15y ago
  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.
- e40 15y ago
  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.

by jvm 15y ago

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.

kenjackson 15y ago

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).

eropple 15y ago
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.
- bennoleslie 15y ago
  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"
  - kelnos 15y ago
    ... 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.
davvid 15y ago
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".
- X-Istence 15y ago
  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.
  - deleted 15y ago
    [deleted]
  - rogerbraun 15y ago
    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 http://www.simson.net/ref/ugh.pdf
    - X-Istence 15y ago
      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.
jvm 15y ago
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.
e40 15y ago
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.