On Mon, Dec 10, 2018 at 7:07 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Elijah Newren <newren@xxxxxxxxx> writes: > > >> Note that 'git checkout -p <tree-ish> -- [<pathspec>]' already works > >> this way, so no changes are needed for the patch mode. We disallow > >> 'git checkout --overlay -p' to avoid confusing users who would expect > >> to be able to force overlay mode in 'git checkout -p' this way. > > > > Whoa...that's interesting. To me, that argues even further that the > > traditional checkout behavior was wrong all along and the choice of > > --overlay vs. --no-overlay in the original implementation was a total > > oversight. I'm really tempted to say that --no-overlay should just be > > the default in checkout too...but maybe that's too high a hill to > > climb, at least for now. > > You are exhibiting a typical reaction to a shiny new toy. > > The original "checkout paths out of the trees and/or the index to > recover what was lost" is modeled after "cp -R .../else/where .", > which is an overlay operation, and you wouldn't imagine complaining > that "cp -R" is wrong not to remove things in the target, to be > equivalent to "rm -fr where && cp -R .../else/where .". > > Each has its own uses. We just didn't have the other half of the > pair. Ah, modelled on cp -R. I think that rather than reacting "to a shiny new toy", I just had always had a different mental model AND failed to figure out what the original model was, leading me to always view it as buggy. Thanks for giving me the model I was missing. > If anything, I would consider "checkout -p" that does not do overlay > is a bug that needs to be fixed. Yeah, --no-overlay being the default for -p, and --overlay being the default otherwise is rather inconsistent. (Though I'm also fine with that being fixed by some future patch series.)
