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

From: Jeff King <peff@peff.net>
Date: Sep 17, 2013, 20:10 UTC
Message-ID: <20130917201003.GA16860@sigill.intra.peff.net>
In-Reply-To: <20130917190659.GA15588@pengutronix.de>

On Tue, Sep 17, 2013 at 09:06:59PM +0200, Uwe Kleine-König wrote:

> 	$ git checkout HEAD^ -- subdir
> 
> I'd expect that subdir/b is removed from the index as this file didn't
> exist in HEAD^ but git-status only reports:

I'm not sure if this is intentional or not. The definition of "git checkout $tree $path" given in commit 0a1283b says:

    Checking paths out of a tree is (currently) defined to do:

     - Grab the paths from the named tree that match the given pathspec,
       and add them to the index;

     - Check out the contents from the index for paths that match the
       pathspec to the working tree; and while at it

     - If the given pathspec did not match anything, suspect a typo from the
       command line and error out without updating the index nor the working
       tree.

So we are applying the pathspec to the named tree, and pulling anything that matches into the index. Which by definition cannot involve a deletion, because there is no comparison happening (so we either have it, or we do not). Whereas what you are expecting is to compare the tree and the index, limited by the pathspec, and pull any changes from the tree into the index.

I tend to agree that the latter is more like how other git commands behave (e.g., if you tried to use "read-tree" to emulate what git-checkout was doing, I think you would end up with a two-way merge). But there may be implications I haven't thought of.

Note also that "git checkout -p" does present "subdir/b" as a deletion. It works by doing a pathspec-limited diff between the two endpoints, which will notice deletions. So there is some inconsistency there with the baseline form.

-Peff