RE: Suggestion: make git checkout safer

["Randall S. Becker" <rsbecker@nexbridge.com>]

On June 3, 2015 3:06 PM Jeff King wrote:
> On Wed, Jun 03, 2015 at 10:32:40AM -0700, Junio C Hamano wrote:
> > "git checkout $paths" (and you can give "." for $paths to mean
> > "everything") is akin to "cp -R $elsewhere/$path ." to restore the
> > working tree copies from somewhere else.
> >
> > "Ouch, 'git checkout .'  overwrote what was in my working tree" is
> > exactly the same kind of confusion as "I ran 'cp -r ../saved .' and it
> > overwrote everything".  As you said in your initial response, that is
> > what the command is meant for.
> >
> > What does that similar command outside world, "cp", have for "more
> > safety"?  'cp -i' asks if the user wants to overwrite a file for each
> > path; perhaps a behaviour similar to that was the original poster
> > wanted to see?
> 
> Yeah, I'd say "cp -i" is the closest thing. I don't have a problem with adding that,
> but I'd really hate for it to be the default (just as I find distros which "alias
> rm='rm -i" annoying).

Brainstorming a few compromises:

or some such config option to turn on behaviour like this:
core.checkout=-i

or some such thing where if there are strictly more than m files being touched and strictly less than n files to act accordingly - a threshold concept:
core.checkout_warn_upperlimit=n # default to 0
core.checkout_warn_lowerlimit=m # default to 0

or in a more gross fashion provide a pre-checkout hook to do all the work of prompting/control of the situation.

Personally I'm happy with the defaults as they are (and was not a fan of defaulting rm -i or cp -i either) but I can see the point and have had diffuse whines from my team on the checkout subject, which is why I'm commenting.