Re: [PATCH] add-interactive: shortcut to add hunk and quit

From: Jeff King <peff@peff.net>
Date: May 19, 2011, 11:02 UTC
Message-ID: <20110519110259.GA11507@sigill.intra.peff.net>
In-Reply-To: <201105191216.51709.trast@student.ethz.ch>

On Thu, May 19, 2011 at 12:16:51PM +0200, Thomas Rast wrote:

Show 8 quoted lines

> 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