Re: git checkout --theirs fails
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 15, 2016, 21:47 UTC
- Message-ID
- <xmqqd1qv76rn.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <CAGZ79kbzrpHowSLfCjB6wVfeX_3MUXAjD0rQdcugryWPMrTazQ@mail.gmail.com>
Stefan Beller <sbeller@google.com> writes:
Show 16 quoted lines
> On Tue, Mar 15, 2016 at 10:27 AM, Phil Susi <phillsusi@gmail.com> 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.