From: Junio C Hamano Date: Mon, 03 Oct 2011 16:08:31 GMT Subject: Re: [RFC/PATCH] git checkout $tree path Message-ID: <7vmxdigirk.fsf@alter.siamese.dyndns.org> In-Reply-To: <20111003102647.GD16078@sigill.intra.peff.net> Jeff King 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).