{"thread":{"id":"41692","subject":"git checkout --theirs fails","startedAt":"2016-03-15T17:27:12Z","lastAt":"2016-03-16T21:12:54Z","messageCount":5,"participants":["Phil Susi","Stefan Beller","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"280813","messageId":"56E845F0.9020609@gmail.com","threadId":"41692","inReplyTo":null,"subject":"git checkout --theirs fails","fromName":"Phil Susi","fromEmail":"phillsusi@gmail.com","sentAt":"2016-03-15T17:27:12Z","receivedAt":"2016-03-15T17:27:12Z","isPatch":false,"sender":{"key":"phillsusi@gmail.com","avatar":null},"body":"I'm doing a rebase and got some conflicts. I just want to take their\nversion of all files, but git checkout --theirs complains:\n\n--ours/--theirs' cannot be used with switching branches\n\nWhat gives? I'm not *trying* to switch branches. I just want to\nresolve the conflict by taking their version. If I try git checkout\n--theirs ., then it complains that not every single file in the\ndirectory has a \"their\" version. So? Take the ones that do.\n"},{"id":"280845","messageId":"CAGZ79kbzrpHowSLfCjB6wVfeX_3MUXAjD0rQdcugryWPMrTazQ@mail.gmail.com","threadId":"41692","inReplyTo":"56E845F0.9020609@gmail.com","subject":"Re: git checkout --theirs fails","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-03-15T21:35:18Z","receivedAt":"2016-03-15T21:35:18Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Mar 15, 2016 at 10:27 AM, Phil Susi wrote:\n> I'm doing a rebase and got some conflicts. I just want to take their\n> version of all files, but git checkout --theirs complains:\n>\n> --ours/--theirs' cannot be used with switching branches\n>\n> What gives? I'm not *trying* to switch branches. I just want to\n> resolve the conflict by taking their version. If I try git checkout\n> --theirs ., then it complains that not every single file in the\n> directory has a \"their\" version. So? Take the ones that do.\n\nI think for checking out files you'd need to add the file names.\nIn case of a collision between branch name and file name, even add\na double dash:\n\n git checkout --theirs -- file/name\n\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"280847","messageId":"xmqqd1qv76rn.fsf@gitster.mtv.corp.google.com","threadId":"41692","inReplyTo":"CAGZ79kbzrpHowSLfCjB6wVfeX_3MUXAjD0rQdcugryWPMrTazQ@mail.gmail.com","subject":"Re: git checkout --theirs fails","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-15T21:47:40Z","receivedAt":"2016-03-15T21:47:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> On Tue, Mar 15, 2016 at 10:27 AM, Phil Susi wrote:\n>> I'm doing a rebase and got some conflicts. I just want to take their\n>> version of all files, but git checkout --theirs complains:\n>>\n>> --ours/--theirs' cannot be used with switching branches\n>>\n>> What gives? I'm not *trying* to switch branches. I just want to\n>> resolve the conflict by taking their version. If I try git checkout\n>> --theirs ., then it complains that not every single file in the\n>> directory has a \"their\" version. So? Take the ones that do.\n>\n> I think for checking out files you'd need to add the file names.\n> In case of a collision between branch name and file name, even add\n> a double dash:\n>\n> git checkout --theirs -- file/name\n\nThat is true, but notice that the last example by Phil gives a dot\nas the pathspec to match all available files.\n\nHaving said that,\n\n $ git checkout --theirs -- file/name\n\nwould fail when the path file/name is unmerged and does not have\nstage #3 entry, wouldn't it? So with \".\", unless all paths that\nmatch that pathspec (i.e. all available files) are either merged\n(i.e. without conflict) or have stage #3 entry, it is expected that\nthe command would fail consistently to the case where a pathspec\n\"file/name\" that happens to match only one path is given, and that\nis the behaviour Phil saw, I would think.\n"},{"id":"280893","messageId":"56E95585.30409@gmail.com","threadId":"41692","inReplyTo":"xmqqd1qv76rn.fsf@gitster.mtv.corp.google.com","subject":"Re: git checkout --theirs fails","fromName":"Phil Susi","fromEmail":"phillsusi@gmail.com","sentAt":"2016-03-16T12:45:57Z","receivedAt":"2016-03-16T12:45:57Z","isPatch":false,"sender":{"key":"phillsusi@gmail.com","avatar":null},"body":"On 3/15/2016 5:47 PM, Junio C Hamano wrote:\n> would fail when the path file/name is unmerged and does not have\n> stage #3 entry, wouldn't it? So with \".\", unless all paths that\n> match that pathspec (i.e. all available files) are either merged\n> (i.e. without conflict) or have stage #3 entry, it is expected that\n> the command would fail consistently to the case where a pathspec\n> \"file/name\" that happens to match only one path is given, and that\n> is the behaviour Phil saw, I would think.\n\nRight... why is this though? Why doesn't it just check out those files\nthat *do* have a #3 entry? And also why the nonsense about switching\nbranches when you don't specify any path or branch?\n"},{"id":"280966","messageId":"20160316211254.GB2200@sigill.intra.peff.net","threadId":"41692","inReplyTo":"56E95585.30409@gmail.com","subject":"Re: git checkout --theirs fails","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-03-16T21:12:54Z","receivedAt":"2016-03-16T21:12:54Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 16, 2016 at 08:45:57AM -0400, Phil Susi wrote:\n\n> On 3/15/2016 5:47 PM, Junio C Hamano wrote:\n> > would fail when the path file/name is unmerged and does not have\n> > stage #3 entry, wouldn't it? So with \".\", unless all paths that\n> > match that pathspec (i.e. all available files) are either merged\n> > (i.e. without conflict) or have stage #3 entry, it is expected that\n> > the command would fail consistently to the case where a pathspec\n> > \"file/name\" that happens to match only one path is given, and that\n> > is the behaviour Phil saw, I would think.\n> \n> Right... why is this though? Why doesn't it just check out those files\n> that *do* have a #3 entry?\n\nCertainly \"git checkout --theirs foo\" should complain if \"foo\" does not\nhave a \"theirs\" entry. But in your case, you are picking the entries up\nonly via a recursive pathspec, so you'd probably be fine if _any_\nentries were updated.\n\nWe do something like that in git-add, where \"git add 'foo*'\" will\ncomplain only if \"foo*\" didn't match anything. I suspect we could do the\nsame here, but nobody has bothered to implement it.\n\nProbably (and now I am in the realm of pure speculation) because\n\"checkout --theirs\" was intended to be done on specific paths, once you\nhad looked at the conflicts. If you want to do a blanket \"checkout\n--theirs .\", wouldn't merging with `-Xtheirs` be simpler?\n\n> And also why the nonsense about switching\n> branches when you don't specify any path or branch?\n\nBecause the default for checkout without any arguments has always been\nto \"switch\" branches to HEAD. That's obviously a noop, but people have\nlong done it to see the switching message.\n\nNobody until now bothered to think about how that decision would\ninteract with \"--theirs\". So it does _a_ logical thing, but not the one\nthat would be most useful to you. I do not think it would be harmful to\nDWIM \"git checkout --theirs\" to \"git checkout --theirs .\".\n\n-Peff\n"}]}