Re: [RFC/PATCH] git checkout $tree path

On Thu, Sep 29, 2011 at 6:46 PM, Junio C Hamano [off-list ref] wrote:
[snip]

According to that definition, because "master" has dir/file1, and the
index is unchanged since "next", we would add dir/file1 to the index, and
then check dir/file1 and dir/file3 out of the index. Hence, we end up
resurrecting dir/file3 out of the index, even though "master" does not
have that path.

This is somewhat surprising.

That is surprising!  It explains something I saw just yesterday which
closely mirrors your recipe.

It may make sense to tweak the semantics a little bit. We can grab the
paths out of the named tree ("master" in this case), update the index, and
update the working tree with only with these paths we grabbed from the
named tree. By doing so, we will keep the local modification to dir/file3
(in this case, the modification is to "delete", but the above observation
hold equally true if dir/file3 were modified).

That seems sane.

An alternative semantics could be to first remove paths that match the
given pathspec from the index, then update the index with paths taken from
the named tree, and update the working tree. "git checkout master dir"
would then mean "replace anything currently in dir with whatever is in dir
in master". It is more dangerous, and it can easily emulated by doing:

This is equally sane, but is probably closer to my expectation.

[snip]

 * This is a behaviour change, but it may qualify as a bugfix. I dunno.

Personally, I lean towards it being a bugfix.

-John