If you’re using reset with uncommitted changes and you’re not intentionally throwing them away, you’re doing something wrong.
git reset —hardmeans “fuck everything, set the state to X”. I only ever use it when I want to throw away the current state.Well yeah I think the point is you’re human and you might make a mistake.
Using
git reset --keepwould just make more work since I’ll have to throw away uncommitted changes anyways. Removing uncommitted changes is kind of the whole point, it is called ‘reset’ after all. If I want to preserve uncommitted changes, I’ll either stash them or commit them to a temporary branch. That has the added benefit of adding those changes to the reflog so if I screw up later I’ll be able to recover them.Let me live with my mistakes
Waddyamean “that’s what backups are for”Sorry, wrong communityNot many people back up continuously, so this is still useful.
This is great advice. I did not know that ‘–keep’ was an option, and have offen done rather lengthy work arounds to achieve this.
I do not actually understand the use case of
—keepover the default—mixed, which I use regularly to restage patches or fuckups. I very frequently use—hardto test something out and blow it away without worrying about any changes. This whole conversation is fascinating because it highlights just how different everyone uses git and equally how bad sweeping generalizations like “—hardis something to avoid” are (without incredibly specific caveats).It seems like
—keepmakes sense if you’re not usingstashbefore trying to change history when you have local, uncommitted changes? That might be why it’s not clicking with me; any time I fuck with history Istashanything local I might want to keep.
