Re: git checkout --theirs fails

From: Jeff King <peff@peff.net>
Date: Mar 16, 2016, 21:12 UTC
Message-ID: <20160316211254.GB2200@sigill.intra.peff.net>
In-Reply-To: <56E95585.30409@gmail.com>

On Wed, Mar 16, 2016 at 08:45:57AM -0400, Phil Susi wrote:

Show 11 quoted lines

> 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