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

[Jeff King <peff@peff.net>]

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

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