4 ms·

tl;dr: User still hasn't learned that committing early and often is a good idea. User blames tools for his ignorance.

by davvid 15y ago

cheald 15y ago
While he could improve his workflow, git had a legit bug in this case. If he was complaining that "OMFG, git reset --hard wiped out my changes!" then we could laugh at him, but git did a Bad Thing here by any reasonable measure.
- davvid 15y ago
  I appreciate the replies but down-voting is silly. Look, I have to deal directly with co-workers that misuse git. When I see them doing something bad, I tell them about it. The biggest resistance has been from those that refuse to change. Here's a real-world example: "git messed up my merge again". What? I go to look into it -- well it turns out they don't understand git and work around it by copying files out of their sandbox, run "git pull", and then copy stuff back in. This is such a recipe for disaster (it easily can and will lose others' changes) that not telling him to "improve his workflow" is disastrous for the project as a whole. Yes, git messed up his merge. But as others have noted, so could have a bad Makefile rule. All I'm suggesting is that by improving his workflow (committing early and often) then there is no chance of work getting lost, ever.
  - cheald 15y ago
    I don't think anyone takes issue with the "fix your workflow" part of your statement; bad workflows should be fixed. They aren't an excuse for bugs in the software, though. A version control system should never unrecoverably wipe out data unless you explicitly ask it to.
    - davvid 15y ago
      Heya, yes, bugs are completely unacceptable. Trust me, the git project completely understands this. Sorry if my comments seemed rude or snarky. Actually, I tend to dislike "tl;dr" comments altogether. I don't think my comment added much to this discussion. If I could I'd delete it. cheers
bennoleslie 15y ago
I'm not sure where you get the idea that I'm not committing early? If it was the comment saying '3 days of straight hacking' then I apologise for my prose being unclear. I was only bringing that up because my first assumption was that after 3 days of hacking I was tired and assumed it was indeed my fault. It was a couple of hours worth of code that needed committing. And doing a pull, which is meant to safely pull in unrelated changes, to test some things before committing, especially when it was a very simple change on head, is completely reasonable. I'm not ignorant about the many ways in which git can be used, the post wasn't even particularly blame placing. Tools have bugs, shit happens. Most of the post was tracking down the bug, which is much more useful. Thankfully it was already fixed, so I didn't need to fix it myself.
- jamieb 15y ago
  And doing a pull, which is meant to safely pull in unrelated changes, to test some things before committing, especially when it was a very simple change on head, is completely reasonable. I don't think its reasonable. 100% of posters here don't think its reasonable. You just demonstrated why its not reasonable. Yet you say its reasonable. Here's my rule for version control: if an operation can go wrong, it will go wrong.

tl;dr: User still hasn't learned that committing early and often is a good idea. User blames tools for his ignorance.

by davvid 15y ago

tl;dr: User still hasn't learned that committing early and often is a good idea. User blames tools for his ignorance.

While he could improve his workflow, git had a legit bug in this case. If he was complaining that "OMFG, git reset --hard wiped out my changes!" then we could laugh at him, but git did a Bad Thing here by any reasonable measure.

davvid 15y ago
I appreciate the replies but down-voting is silly. Look, I have to deal directly with co-workers that misuse git. When I see them doing something bad, I tell them about it. The biggest resistance has been from those that refuse to change. Here's a real-world example: "git messed up my merge again". What? I go to look into it -- well it turns out they don't understand git and work around it by copying files out of their sandbox, run "git pull", and then copy stuff back in. This is such a recipe for disaster (it easily can and will lose others' changes) that not telling him to "improve his workflow" is disastrous for the project as a whole. Yes, git messed up his merge. But as others have noted, so could have a bad Makefile rule. All I'm suggesting is that by improving his workflow (committing early and often) then there is no chance of work getting lost, ever.
- cheald 15y ago
  I don't think anyone takes issue with the "fix your workflow" part of your statement; bad workflows should be fixed. They aren't an excuse for bugs in the software, though. A version control system should never unrecoverably wipe out data unless you explicitly ask it to.
  - davvid 15y ago
    Heya, yes, bugs are completely unacceptable. Trust me, the git project completely understands this. Sorry if my comments seemed rude or snarky. Actually, I tend to dislike "tl;dr" comments altogether. I don't think my comment added much to this discussion. If I could I'd delete it. cheers

bennoleslie 15y ago

I'm not sure where you get the idea that I'm not committing early? If it was the comment saying '3 days of straight hacking' then I apologise for my prose being unclear. I was only bringing that up because my first assumption was that after 3 days of hacking I was tired and assumed it was indeed my fault. It was a couple of hours worth of code that needed committing. And doing a pull, which is meant to safely pull in unrelated changes, to test some things before committing, especially when it was a very simple change on head, is completely reasonable. I'm not ignorant about the many ways in which git can be used, the post wasn't even particularly blame placing. Tools have bugs, shit happens. Most of the post was tracking down the bug, which is much more useful. Thankfully it was already fixed, so I didn't need to fix it myself.

jamieb 15y ago
And doing a pull, which is meant to safely pull in unrelated changes, to test some things before committing, especially when it was a very simple change on head, is completely reasonable. I don't think its reasonable. 100% of posters here don't think its reasonable. You just demonstrated why its not reasonable. Yet you say its reasonable. Here's my rule for version control: if an operation can go wrong, it will go wrong.