On Thu, Sep 29, 2011 at 03:46:31PM -0700, Junio C Hamano wrote:
> 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.
Agreed, it is surprising.
> 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).
Hmm. I can see that being what the user expects in some cases. For
example, when "master" has nothing to do with dir/file3 in the first
place. But I can also see this:
> 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:
being what the user expects. As in, "master deleted this file; shouldn't
checkout pull the deletion to my new branch when I ask it to?".
But we can't distinguish those two cases without actually having a merge
base. And this isn't a merge; it's not about picking changes from
master, it's about saying "make dir look like it does in master". So
in that sense, the most straightforward thing is your second
alternative: afterwards, we should have only the files in "dir" that
master has.
A related question is what does this do:
git reset master -- dir
My mental model is that it makes the index for "dir" look just like
master:dir. And that seems pretty accurate; it deletes dir/file3 (which
does not exist in "master") from the index.
My mental model of "git checkout master -- dir" is similar. It should
make the index for "dir" look like master:dir, and then check that out.
IOW, I think of it as:
git reset master -- dir &&
git checkout -- dir
Maybe that is not accurate (well, clearly it does not match the current
behavior), but I think it is at least easy to explain and relatively
sane. So it is something to shoot for, and makes "git checkout"
consistent with "git reset".
> * This is a behaviour change, but it may qualify as a bugfix. I dunno.
I think it is a bug. I can see both of the alternatives you outlined
above making some sense, but checking out content that has _nothing_ to
do with master is just confusing. Either make it look like master, or
leave it alone.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html