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

From: Jeff King <peff@peff.net>
Date: Sep 17, 2013, 21:21 UTC
Message-ID: <20130917212106.GB20178@sigill.intra.peff.net>
In-Reply-To: <xmqq1u4nxjv2.fsf@gitster.dls.corp.google.com>

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

Show 8 quoted lines

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

Show 11 quoted lines

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