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