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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 3, 2011, 16:08 UTC
Message-ID: <7vmxdigirk.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20111003102647.GD16078@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 6 quoted lines

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