All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.