# git checkout --theirs fails 5 messages from 2016-03-15 to 2016-03-16. Participants: Phil Susi, Stefan Beller, Junio C Hamano, Jeff King. Thread: https://gitlist.dev/t/41692 ## Phil Susi, 2016-03-15 17:27 Subject: git checkout --theirs fails Message-ID: <56E845F0.9020609@gmail.com> URL: https://gitlist.dev/e/56E845F0.9020609%40gmail.com ``` I'm doing a rebase and got some conflicts. I just want to take their version of all files, but git checkout --theirs complains: --ours/--theirs' cannot be used with switching branches What gives? I'm not *trying* to switch branches. I just want to resolve the conflict by taking their version. If I try git checkout --theirs ., then it complains that not every single file in the directory has a "their" version. So? Take the ones that do. ``` ## Stefan Beller, 2016-03-15 21:35 Subject: Re: git checkout --theirs fails Message-ID: URL: https://gitlist.dev/e/CAGZ79kbzrpHowSLfCjB6wVfeX_3MUXAjD0rQdcugryWPMrTazQ%40mail.gmail.com In-Reply-To: <56E845F0.9020609@gmail.com> ``` On Tue, Mar 15, 2016 at 10:27 AM, Phil Susi wrote: > I'm doing a rebase and got some conflicts. I just want to take their > version of all files, but git checkout --theirs complains: > > --ours/--theirs' cannot be used with switching branches > > What gives? I'm not *trying* to switch branches. I just want to > resolve the conflict by taking their version. If I try git checkout > --theirs ., then it complains that not every single file in the > directory has a "their" version. So? Take the ones that do. I think for checking out files you'd need to add the file names. In case of a collision between branch name and file name, even add a double dash: git checkout --theirs -- file/name > > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ``` ## Junio C Hamano, 2016-03-15 21:47 Subject: Re: git checkout --theirs fails Message-ID: URL: https://gitlist.dev/e/xmqqd1qv76rn.fsf%40gitster.mtv.corp.google.com In-Reply-To: ``` Stefan Beller writes: > On Tue, Mar 15, 2016 at 10:27 AM, Phil Susi wrote: >> I'm doing a rebase and got some conflicts. I just want to take their >> version of all files, but git checkout --theirs complains: >> >> --ours/--theirs' cannot be used with switching branches >> >> What gives? I'm not *trying* to switch branches. I just want to >> resolve the conflict by taking their version. If I try git checkout >> --theirs ., then it complains that not every single file in the >> directory has a "their" version. So? Take the ones that do. > > I think for checking out files you'd need to add the file names. > In case of a collision between branch name and file name, even add > a double dash: > > git checkout --theirs -- file/name That is true, but notice that the last example by Phil gives a dot as the pathspec to match all available files. Having said that, $ git checkout --theirs -- file/name 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. ``` ## Phil Susi, 2016-03-16 12:45 Subject: Re: git checkout --theirs fails Message-ID: <56E95585.30409@gmail.com> URL: https://gitlist.dev/e/56E95585.30409%40gmail.com In-Reply-To: ``` 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? And also why the nonsense about switching branches when you don't specify any path or branch? ``` ## Jeff King, 2016-03-16 21:12 Subject: Re: git checkout --theirs fails Message-ID: <20160316211254.GB2200@sigill.intra.peff.net> URL: https://gitlist.dev/e/20160316211254.GB2200%40sigill.intra.peff.net In-Reply-To: <56E95585.30409@gmail.com> ``` 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 ```