Re: [BUG?] git checkout $commit -- somedir doesn't drop files

On Tue, Sep 17, 2013 at 01:40:17PM -0700, Junio C Hamano wrote:

quoted

Hrm. Probably not. It is almost a one-way merge going to the named tree
(but limited by the pathspec), except that I think the current
git-checkout code may provide some safety checks related to where we are
coming from (e.g., do we unconditionally overwrite entries that are not
uptodate?).

I think we do unconditionally overwrite and that has been very much
on purpose.

I thought so, too, but I was thrown off by the code in checkout_paths()
that warns/aborts if there are unmerged entries. But it looks like we
will have thrown out those entries already during the read_tree_some
call, which adds the new entries using OK_TO_REPLACE.

"git checkout tree-ish -- file.txt" has always been about replacing
whatever cruft is in paths in the worktree that match pathspec, just
like "cat content-created-elsewhere >file.txt" is.  "Oops, you have
a local change that do not match index" is the last thing we want to
say, because getting rid of that local change is the primary reason
why "checkout tree-ish -- file.txt" exists.

Taking the state of a subdirectory as a whole as "content", the
change we are discussing will make it more like "rm -fr dir && tar
xf some-content dir" to replace the directory wholesale, which I
personally think is a good thing in the longer term.

Yeah, that makes sense. What about untracked files?

Right now we overwrite them if the tree-ish has an entry at the same
path; that is a bit more dangerous than the rest of git, but does match
the "ignore local modifications" rule. I assume if we handled deletions,
though, that we would simply leave them be.

So given that, is it fair to say that a one-way "go here" merge, limited
by pathspec, is the closest equivalent?

-Peff