From: Michael J Gruber <git@drmicha•warpmail.net>
To: "Armin Ronacher" <armin.ronacher@active-4•com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail•com>
Cc: Git Mailing List <git@vger•kernel.org>
Subject: Re: Experience with Recovering From User Error (And suggestions for improvements)
Date: Wed, 18 Feb 2015 10:46:28 +0100 [thread overview]
Message-ID: <54E45F74.6080907@drmicha.warpmail.net> (raw)
In-Reply-To: <54E1F0AF.1070403@active-4.com>
Armin Ronacher venit, vidit, dixit 16.02.2015 14:29:
> Hi,
>
> On 16/02/15 13:09, Ævar Arnfjörð Bjarmason wrote:
>> We should definitely make recovery like this harder, but is there a
>> reason for why you don't use "git reset --keep" instead of --hard?
> This was only the second time in years of git usage that the reset was
> incorrectly done. I suppose at this point I might try to retrain my
> muscle memory to type something else :)
>
>> If we created such hooks for "git reset --hard" we'd just need to
>> expose some other thing as that low-level operation (and break scripts
>> that already rely on it doing the minimal "yes I want to change the
>> tree no matter what" thing), and then we'd just be back to square one
>> in a few years when users started using "git reset --really-hard" (or
>> whatever the flag would be).
> I don't think that's necessary, I don't think it would make the
> operation much slower to just make a dangling commit and write out a few
> blobs. The garbage collect will soon enough take care of that data
> anyways. But I guess that would need testing on large trees to see how
> bad that goes.
>
> I might look into the git undo thing that was mentioned.
>
>
> Regards,
> Armin
>
Are you concerned about the index only, not unstaged worktree changes?
In this case, keeping a reflog for the index may help, and it would
somehow fit into the overall concept.
Otherwise, we would basically need a full stash before a hard reset.
That's not the first time where we could need a distinction between
"command run by user" and "command run by script". For the former, we
could allow overriding default options, re-aliasing internal commands,
adding expensive safety hooks. For the latter we can't.
It's just that we don't have such a concept yet (other than checking tty).
Michael
next prev parent reply other threads:[~2015-02-18 9:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-16 10:41 Experience with Recovering From User Error (And suggestions for improvements) Armin Ronacher
2015-02-16 12:09 ` Æ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 [this message]
[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=54E45F74.6080907@drmicha.warpmail.net \
--to=git@drmicha$(echo .)warpmail.net \
--cc=armin.ronacher@active-4$(echo .)com \
--cc=avarab@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox