On Mon, Oct 3, 2011 at 6:26 AM, Jeff King <peff@xxxxxxxx> wrote: > On Thu, Sep 29, 2011 at 03:46:31PM -0700, Junio C Hamano wrote: >> 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. I think I'd expect the first behavior with: $ git checkout master -- dir/* And the second with: $ git checkout master -- dir $0.02. j. -- 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