git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).