Jeff King <p...@peff.net> writes: > If we want to introduce more safety here, I'd be inclined to perform the > operation by default, but give a better escape hatch. For example, by > creating a loose object for any file we're about to overwrite, and > possibly writing an entry into a log.
Can we borrow the ideas from other tools that have similar characteristics, I wonder. "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? -- 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
