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