5 ms·
> Last friday I lost a commit using git reset --HARD You don't lose a commit just because you use git reset --hard. The author either doesn't know how git bran
by tomlu 12y ago
> Last friday I lost a commit using git reset --HARD
You don't lose a commit just because you use git reset --hard. The author either doesn't know how git branches work and/or how to use reflog, or he means to say he lost the uncommitted content of his working tree.
- matheusml 12y agoIt was 'git reset --HARD <commit-id>', like a cherry pick, before pushing.
- X-Istence 12y agogit reflog Might be your saviour here next time.
- matheusml 12y agoI'll update the post. This worked for me. Thanks a lot!
- yuvadam 12y agoIf it was "before pushing" that means the commit has been made, and thus isn't lost (but accessible via the reflog.)
- micampe 12y agoEven with --hard, the commit isn't lost. Commits are not immediately removed from the repository, only when git runs the garbage collection. Try it: create a test commit, make a note of its hash, reset to HEAD~1 and then reset again to that hash. When you do this by mistake and you don't know the hash you can find it using git reflog, which logs everything that happens in the repository. More detailed: http://gitready.com/intermediate/2009/02/09/reflog-your-safety-net.html http://gitready.com/intermediate/2009/02/09/reflog-your-safe...
- davvid 12y agogit reset --hard These days there's little reason to do reset --hard. `git reset --merge` is much safer and can be used almost anytime you would have otherwise done `--hard`. e.g. if you want to force your branch to point at "foo", you can `git reset --merge foo` and it'll bail out if it detects that you have uncommitted edits that would have been lost by moving to "foo". If it can safely move the uncommitted edits there, it'll do it.