Jeff King <peff@xxxxxxxx> 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).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html