4 ms·

How is it relevant how long it was since he last committed? It sounds from the description like this could happen if he'd committed five minutes before. It's s

How is it relevant how long it was since he last committed? It sounds from the description like this could happen if he'd committed five minutes before. It's still not cool to clobber work like that.

EdiX 15y ago
Normally in git you never pull on a dirty working dir, you either stash or commit your work and then pull. That's why this bug is unlikely to trigger normally.
- bobwaycott 15y ago
  Exactly what I was thinking. I'd have done: git fetch git stash git pull --rebase branch-name git stash apply All this cp business struck me as a bit of not understanding how to properly work with git. I've never had my work clobbered by following the strategy above. But I also don't go very long between commits on my working branch.
  - mainguy 15y ago
    Your workflow is a little overcomplicated.. I think the following will produce identical results: git pull --rebase branch-name
    - jrockway 15y ago
      He is using "git stash" to create a commit object for his uncommitted changes, giving him more documentation in the event that Something Goes Wrong. Git will never throw away your data, but you might get into a weird mental state and type a command that throws away your data. By creating a commit object, you can always get back to that state, and you have a little one-line note-to-self that helps you not get into a weird mental state. I personally do a "real" commit before rebase, but "git stash" is really the exact same thing. I guess "git stash pop" is less scary than "git rebase HEAD^". Either way, you can always undo that operation via the reflog.
ajross 15y ago
Of course it's not cool. It's a bug, and it was fixed. But the relevancy is to the title and summary. When you say "git destroyed my data" it sounds like you're saying that git lost commited data in the repo. What actually happened here is that the working tree got clobbered. That is a vastly less problematic situation. Working trees get clobbered all the time: rogue "make clean" changes, system crashes, someone-stole-my-laptop, errant rm -rf, forgetting which tree your changes are in... I've lost working data to every one of these, and I never felt the need to blame my tools in a blog post. So yeah. It's a bug (and a pretty embarassing one). It was fixed. Is there anything more to say? Move along.
- click170 15y ago
  To add, it's commendable that he tracked down the bug himself, at least I think so. Many people would throw their hands up in the air and walk away with a sour disposition, but props to this guy for working it out to the end.
- joe_the_user 15y ago
  If "make clean" clobbered a source directory without me making an error in my make file, I would be rather miffed. "All software has bugs, but bugs that destroy data are pretty devastating." It's hard not to agree with this...
  - ajross 15y ago
    The point was more that if you've ever written a "make clean" rule, you've probably blown away your source tree a few times trying to do it. The software development working directory is the wild west. Bugs that destroy data here, frankly, don't rise anywhere near "devastating" in my book, sorry.
ajross 15y ago
Of course it's not cool. It's a bug, and it was fixed. But the relevancy is to the title and summary. When you say "git destroyed my data" it sounds like you're saying that git lost commited data in the repo. What actually happened here is that the working tree got clobbered. That is a vastly less problematic situation. Working trees get clobbered all the time: rogue "make clean" changes, system crashes, someone-stole-my-laptop, errant rm -rf, forgetting which tree your changes are in... I've lost working data to every one of these, and I never felt the need to blame my tools in a blog post. So yeah. It's a bug (and a pretty embarassing one). It was fixed. Is there anything more to say? Move along.
deleted 15y ago
[deleted]
astrodust 15y ago
Some people write their entire Ph.D. research papers on a computer that's never backed up, not even once in years. This behavior should be stomped out in first year as a mandatory course, right along CPR.

How is it relevant how long it was since he last committed? It sounds from the description like this could happen if he'd committed five minutes before. It's still not cool to clobber work like that.

EdiX 15y ago

Normally in git you never pull on a dirty working dir, you either stash or commit your work and then pull. That's why this bug is unlikely to trigger normally.

bobwaycott 15y ago
Exactly what I was thinking. I'd have done: git fetch git stash git pull --rebase branch-name git stash apply All this cp business struck me as a bit of not understanding how to properly work with git. I've never had my work clobbered by following the strategy above. But I also don't go very long between commits on my working branch.
- mainguy 15y ago
  Your workflow is a little overcomplicated.. I think the following will produce identical results: git pull --rebase branch-name
  - jrockway 15y ago
    He is using "git stash" to create a commit object for his uncommitted changes, giving him more documentation in the event that Something Goes Wrong. Git will never throw away your data, but you might get into a weird mental state and type a command that throws away your data. By creating a commit object, you can always get back to that state, and you have a little one-line note-to-self that helps you not get into a weird mental state. I personally do a "real" commit before rebase, but "git stash" is really the exact same thing. I guess "git stash pop" is less scary than "git rebase HEAD^". Either way, you can always undo that operation via the reflog.

ajross 15y ago

Of course it's not cool. It's a bug, and it was fixed. But the relevancy is to the title and summary. When you say "git destroyed my data" it sounds like you're saying that git lost commited data in the repo. What actually happened here is that the working tree got clobbered. That is a vastly less problematic situation. Working trees get clobbered all the time: rogue "make clean" changes, system crashes, someone-stole-my-laptop, errant rm -rf, forgetting which tree your changes are in... I've lost working data to every one of these, and I never felt the need to blame my tools in a blog post. So yeah. It's a bug (and a pretty embarassing one). It was fixed. Is there anything more to say? Move along.

click170 15y ago
To add, it's commendable that he tracked down the bug himself, at least I think so. Many people would throw their hands up in the air and walk away with a sour disposition, but props to this guy for working it out to the end.
joe_the_user 15y ago
If "make clean" clobbered a source directory without me making an error in my make file, I would be rather miffed. "All software has bugs, but bugs that destroy data are pretty devastating." It's hard not to agree with this...
- ajross 15y ago
  The point was more that if you've ever written a "make clean" rule, you've probably blown away your source tree a few times trying to do it. The software development working directory is the wild west. Bugs that destroy data here, frankly, don't rise anywhere near "devastating" in my book, sorry.

ajross 15y ago

deleted 15y ago

[deleted]

astrodust 15y ago

Some people write their entire Ph.D. research papers on a computer that's never backed up, not even once in years. This behavior should be stomped out in first year as a mandatory course, right along CPR.