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

From: Jeff King <peff@peff.net>
Date: Oct 4, 2011, 07:42 UTC
Message-ID: <20111004074212.GB7308@sigill.intra.peff.net>
In-Reply-To: <7vmxdigirk.fsf@alter.siamese.dyndns.org>

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

Show 7 quoted lines

> 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