Re: [RFC/PATCH] git checkout $tree path

On Mon, Oct 03, 2011 at 09:08:31AM -0700, Junio C Hamano wrote:

We can think of it both ways, but the "make it look like the other one"
unfortunately is too big a departure from the traditional semantics. At
least I wanted "checkout master -- $path" to mean "I want to copy $path
out of master and _overlay_ that on top of what I have now", similar to
the way how "tar xf master.tar $path" and "cp -r ../master/$path $path"
would be used, so that the command can help the user advance what is in
progress and already underway in $path in the current working tree.

Yeah, I think the "overlay" semantics at least makes some sense. The
strongest argument for "replace" semantics is that "git reset <path>"
uses them, and it would be nice if they were consistent. But I agree
that the overlay is closer to what happens now.

Replacing could be easily done with "git rm -r [--cached] $path" followed
by "git checkout $tree $path" under the original semantics, but overlaying
is not very easily done if "git checkout $tree $path" had your "make $path
look like it does in $tree" semantics.

True.

The change brought in by the RFC/PATCH does change the behaviour, and I am
fairly comfortable now to say that it is a bugfix ("copy and overlay" a la
"tar xf" never clobbers/removes files not in the source, but the current
code does).

That sounds good to me, and I think properly doing a pure overlay is way
better than the prior behavior.

This is sufficiently tricky and subtle that it is probably worth
future-proofing with some tests (e.g., the example you gave in the
commit message).

-Peff