On Tue, 30 Dec 2008, Junio C Hamano wrote: > "Boyd Stephen Smith Jr." <bss@xxxxxxxxxxxxxxxxx> writes: > > > On Tuesday 2008 December 30 20:30:46 Conor Rafferty wrote: > >> MERCURIAL: > >> > >> Update > >> hg update [-C] [-d DATE] [[-r] REV] > > > > Which is the role of "git checkout <branch>" > > > > "git checkout <branch> <paths>" is similar to "hg revert -r <branch> <paths>", > > No it is not. > > The form of the command is makes this request: > > Please look into that named <tree-ish>, and check out the named > <paths> out of it to my work tree. Because the reason I want them in > my work tree is so that I can include them as part of the next commit > I am preparing to create in the index, please update these paths in my > index while at it. With that description, there's a bug: in addition to the above, it checks out from the index any path which does match the <paths> but isn't in <tree-ish>. I think the way to fix that would be to update the work tree from read_tree_some() instead of using the "if pathspec_match() ... checkout_entry()" loop over the index. With the current code, you can have git check out a file that you've changed/deleted from a tree that doesn't contain it at all (and you get the index version). E.g.: $ rm wt-status.c $ git checkout e83c5163316f89bfbde7d9ab23ca2e25604af290 wt-status.c $ ls wt-status.c wt-status.c (instead, you should get an error if a <path> doesn't match anything in the <tree-ish> and only get those things that it matches in the <tree-ish>.) I think I was too zealous sharing code back in February. I should have a patch by the weekend if nobody beats me to it. (And I still think that, if you hit this case, you must be confused, but git isn't helping by doing what it does.) -Daniel *This .sig left intentionally blank* -- 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
