From: Jeff King <peff@peff.net>
To: Thomas Rast <trast@student.ethz.ch>
Cc: Junio C Hamano <gitster@pobox.com>,
Michael J Gruber <git@drmicha.warpmail.net>,
Pete Harlan <pgit@pcharlan.com>,
Hermann Gausterer <git-mailinglist@mrq1.org>,
git list <git@vger.kernel.org>
Subject: Re: [PATCH] add-interactive: shortcut to add hunk and quit
Date: Thu, 19 May 2011 07:02:59 -0400 [thread overview]
Message-ID: <20110519110259.GA11507@sigill.intra.peff.net> (raw)
In-Reply-To: <201105191216.51709.trast@student.ethz.ch>
On Thu, May 19, 2011 at 12:16:51PM +0200, Thomas Rast wrote:
> Junio C Hamano wrote:
> >
> > I think "single-key" was a poorly designed attempt to improve productivity
> > the ("y" <RET>)*5 into "y"*5
>
> Actually for me it more often is
>
> y RET n RET *think* y RET s RET n RET ...
Yeah. I personally find the concept of "5y" crazy; how do you know that
it is 5, and not 4 or 6, if you haven't yet seen them?
But that just means I don't have any use for it; I don't have a real
objection to it.
> After my little accident I'm also considering an (optional?) safety
> question at the end when in checkout -p mode, since it's inherently
> destructive. Of course that first requires changing the whole
> operation to be atomic.
I think a confirmation question is a bad idea. It helps with
fat-fingering, but not much else. 99% of the time you will say "yes",
because of course you just looked through the changes and want to
finalize them. So you will start to hit "y" without looking or thinking,
and it becomes a mere annoyance, until the time you _do_ actually lose
some data by hitting "y" without thinking.
At least that's what would happen to me. :)
I think a much better safety valve is to store the user's worktree state
that we are about to destroy. Then when they accidentally erase
something, whether they realize it immediately, or even 5 minutes later,
it is recoverable. And in the common case where everything goes well,
they needn't be bothered at all.
This fits much better with other git recovery mechanisms, too, which
tend to be one of:
1. Store the previous state, and optionally instruct the user on how
to recover in the case of error (e.g., reflogs, the new orphan
checkout warning).
2. Force the user to give confirmation (e.g., "branch -D"), but _only_
if we have detected some abnormally dangerous situation (e.g., you
are deleting a branch that hasn't been merged anywhere). The user
is more likely to pay attention and think about the confirmation
because we _don't_ ask every time, and because we are giving them
additional information that will help in making the decision.
-Peff
next prev parent reply other threads:[~2011-05-19 11:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-15 12:55 [PATCH] add-interactive: shortcut for add hunk and quit Hermann Gausterer
2011-05-15 20:30 ` Junio C Hamano
2011-05-16 16:26 ` [PATCH] add-interactive: shortcut to " Hermann Gausterer
2011-05-16 16:37 ` Matthieu Moy
2011-05-17 5:09 ` Junio C Hamano
2011-05-17 7:12 ` Hermann Gausterer
2011-05-18 6:40 ` Pete Harlan
2011-05-18 6:45 ` Jeff King
2011-05-18 9:26 ` Michael J Gruber
2011-05-18 15:28 ` Junio C Hamano
2011-05-19 10:16 ` Thomas Rast
2011-05-19 11:02 ` Jeff King [this message]
2011-05-19 19:25 ` Junio C Hamano
2011-05-19 19:42 ` Jeff King
2011-05-18 8:43 ` Hermann Gausterer
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=20110519110259.GA11507@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git-mailinglist@mrq1.org \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pgit@pcharlan.com \
--cc=trast@student.ethz.ch \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).