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

Jeff King [off-list ref] writes:

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

quoted

Jeff King [off-list ref] writes:

quoted

On Tue, Sep 17, 2013 at 12:58:07PM -0700, Junio C Hamano wrote:

quoted

I could argue that the above intended behaviour is suboptimal and it
should have been "the resulting paths in the index and the work tree
that match the given pathspec must be identical to that of the
tree-ish".  In the resulting index or working tree, paths that match
"subdir" pathspec in the above result is subdir/a and subdir/b, and
that is different from what exists in the given tree-ish (which has
only subdir/a and not subdir/b), and under that modified definition,
what the current one does is not correct.

Our emails just crossed, but I basically ended up saying a similar
thing.  Could we simply replace the "update_some" in builtin/checkout.c
with a two-way merge via unpack-trees?

Would it work to resolve a conflicted index by checking out from a
known tree?

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.

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

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