If you’re using reset with uncommitted changes and you’re not intentionally throwing them away, you’re doing something wrong. git reset —hard means “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 --keep would 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 community
Not 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 —keep over the default —mixed, which I use regularly to restage patches or fuckups. I very frequently use —hard to 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 “—hard is something to avoid” are (without incredibly specific caveats).
It seems like —keep makes sense if you’re not using stash before 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 I stash anything local I might want to keep.
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Resources
Rules
Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.