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

From: John Szakmeister <john@szakmeister.net>
Date: Sep 30, 2011, 01:02 UTC
Message-ID: <CAEBDL5VD1nkVK1b_zN+jFAnSrK5X3va0nMdUwypghBcFbz2s0Q@mail.gmail.com>
In-Reply-To: <7vk48rq854.fsf@alter.siamese.dyndns.org>

On Thu, Sep 29, 2011 at 6:46 PM, Junio C Hamano <gitster@pobox.com> wrote: [snip]

Show 7 quoted lines

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

Show 6 quoted lines

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

Show 5 quoted lines

> 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