On 12/11, Junio C Hamano 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. I wonder whether it's worth introducing a config option for this, so people could use this new mode by default if they wanted to, without having to type the extra argument? 'git checkout' is a plumbing command, but I see that some of the shell scripts in git.git are using it. Though they are only using it in the checkout branch mode, rather than the checkout paths mode. > 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. > > If anything, I would consider "checkout -p" that does not do overlay > is a bug that needs to be fixed. >
