From: Armin Ronacher <armin.ronacher@active-4.com>
To: git@vger.kernel.org
Subject: Experience with Recovering From User Error (And suggestions for improvements)
Date: Mon, 16 Feb 2015 11:41:49 +0100 [thread overview]
Message-ID: <54E1C96D.2080109@active-4.com> (raw)
Hi,
Long story short: I failed big time yesterday with accidentally
executing git reset hard in the wrong terminal window but managed to
recover my changes from the staging area by manually examining blobs
touched recently.
After that however I figured I might want to add a precaution for myself
that would have helped there. git fsck is quite nice, but unfortunately
it does not help if you do not have a commit. So I figured it might be
nice to create a dangling backup commit before a reset which would have
helped me. Unfortunately there is currently no good way to hook into
git reset.
Things I noticed in the process:
* for recovering blobs, going through the objects itself was more
useful because they were all recent changes and as such I could
order by timestamp. git fsck will not provide any timestamps
(which generally makes sense, but made it quite useless for me)
* Recovering from blobs is painful, it would be nice if git reset
--hard made a dangling dummy commit before :)
* There is no pre-commit hook which could be used to implement the
previous suggestion.
Would it make sense to introduce a `pre-commit` hook for this sort of
thing or even create a dummy commit by default? I did a quick googling
around and it looks like I was not the first person who made this
mistake. Github's windows client even creates dangling backup commits
in what appears to be fixed time intervals.
I understand that ultimately this was a user error on my part, but it
seems like a small change that could save a lot of frustration.
Regards,
Armin
next reply other threads:[~2015-02-16 10:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-16 10:41 Armin Ronacher [this message]
2015-02-16 12:09 ` Experience with Recovering From User Error (And suggestions for improvements) Ævar Arnfjörð Bjarmason
2015-02-16 12:10 ` Ævar Arnfjörð Bjarmason
2015-02-16 12:37 ` Duy Nguyen
2015-02-16 13:29 ` Armin Ronacher
2015-02-18 9:46 ` Michael J Gruber
[not found] ` <19A600EC-080C-48F1-A949-9A32AFC247E7@gmail.com>
2015-02-19 11:01 ` Michael J Gruber
2015-02-19 12:34 ` [RFD/PATCH] stash: introduce checkpoint mode Michael J Gruber
2015-02-19 13:58 ` Kyle J. McKay
2015-02-19 17:49 ` Junio C Hamano
2015-02-19 23:43 ` Kyle J. McKay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54E1C96D.2080109@active-4.com \
--to=armin.ronacher@active-4.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.