On Wed, Mar 16, 2016 at 08:45:57AM -0400, Phil Susi wrote: > On 3/15/2016 5:47 PM, Junio C Hamano wrote: > > would fail when the path file/name is unmerged and does not have > > stage #3 entry, wouldn't it? So with ".", unless all paths that > > match that pathspec (i.e. all available files) are either merged > > (i.e. without conflict) or have stage #3 entry, it is expected that > > the command would fail consistently to the case where a pathspec > > "file/name" that happens to match only one path is given, and that > > is the behaviour Phil saw, I would think. > > Right... why is this though? Why doesn't it just check out those files > that *do* have a #3 entry? Certainly "git checkout --theirs foo" should complain if "foo" does not have a "theirs" entry. But in your case, you are picking the entries up only via a recursive pathspec, so you'd probably be fine if _any_ entries were updated. We do something like that in git-add, where "git add 'foo*'" will complain only if "foo*" didn't match anything. I suspect we could do the same here, but nobody has bothered to implement it. Probably (and now I am in the realm of pure speculation) because "checkout --theirs" was intended to be done on specific paths, once you had looked at the conflicts. If you want to do a blanket "checkout --theirs .", wouldn't merging with `-Xtheirs` be simpler? > And also why the nonsense about switching > branches when you don't specify any path or branch? Because the default for checkout without any arguments has always been to "switch" branches to HEAD. That's obviously a noop, but people have long done it to see the switching message. Nobody until now bothered to think about how that decision would interact with "--theirs". So it does _a_ logical thing, but not the one that would be most useful to you. I do not think it would be harmful to DWIM "git checkout --theirs" to "git checkout --theirs .". -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