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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html