3 ms·

While it's true that they can't be recovered through the "normal" safety mechanisms, they can certainly be recovered - that too up to 30 days in most cases. `g

While it's true that they can't be recovered through the "normal" safety mechanisms, they can certainly be recovered - that too up to 30 days in most cases. `git fsck` can help here [0]. Also when a stash is dropped, it's SHA is printed to the console. If the console buffer hasn't been cleared and you realise it soon enough, recovery can be quite straightforward. [0]: http://stackoverflow.com/questions/89332/how-to-recover-a-dropped-stash-in-git http://stackoverflow.com/questions/89332/how-to-recover-a-dr...

dahart 10y ago
Yep true, and to be fair to the man page, that's the next sentence after the one I quoted. But, fsck is a big hammer, and most people I've had to help recover their stashes completely glaze over when they see commands named fsck and reflog. Some people when faced with fsck opt to give up and recreate the lost changes, it's that intimidating. And why not just avoid accidents? git's role in life is to be a safety net. Stash is hanging halfway over the edge of the net. Yes it's still possible to recover from accidents, but it's harder. That alone makes it more dangerous. It should be hard to screw up, not hard to recover.
- dasil003 10y ago
  You're right of course, but whereas for a lot of purposes I understand the impulse of "I don't have time to learn this". For so many things that's the right call, but for a developer using git I would like to insert the brain worm that maybe it isn't. I consider git to be on the short list of career-long tools. The rest of the list is linux, bash and vim. Knowledge of these things has a long half life and will serve me across jobs. Even a language I've used for 10+ years in my daily work like Ruby is more likely to become obsolete within my career than git. And the thought of using git without understanding reflog is anxiety producing. The beauty of git is not in memorizing its arcane syntax, it's in understanding the elegant data model. That's my case for why every developer should at least know git-reflog. git-fsck I have to admit never having used :)

dahart 10y ago

Yep true, and to be fair to the man page, that's the next sentence after the one I quoted. But, fsck is a big hammer, and most people I've had to help recover their stashes completely glaze over when they see commands named fsck and reflog. Some people when faced with fsck opt to give up and recreate the lost changes, it's that intimidating. And why not just avoid accidents? git's role in life is to be a safety net. Stash is hanging halfway over the edge of the net. Yes it's still possible to recover from accidents, but it's harder. That alone makes it more dangerous. It should be hard to screw up, not hard to recover.

dasil003 10y ago
You're right of course, but whereas for a lot of purposes I understand the impulse of "I don't have time to learn this". For so many things that's the right call, but for a developer using git I would like to insert the brain worm that maybe it isn't. I consider git to be on the short list of career-long tools. The rest of the list is linux, bash and vim. Knowledge of these things has a long half life and will serve me across jobs. Even a language I've used for 10+ years in my daily work like Ruby is more likely to become obsolete within my career than git. And the thought of using git without understanding reflog is anxiety producing. The beauty of git is not in memorizing its arcane syntax, it's in understanding the elegant data model. That's my case for why every developer should at least know git-reflog. git-fsck I have to admit never having used :)