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

Jeff King [off-list ref] writes:

But we can't distinguish those two cases without actually having a merge
base. And this isn't a merge; it's not about picking changes from
master, it's about saying "make dir look like it does in master". So
in that sense, the most straightforward thing is your second
alternative: afterwards, we should have only the files in "dir" that
master has.

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.

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.

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).