* git checkout --theirs fails
@ 2016-03-15 17:27 Phil Susi
2016-03-15 21:35 ` Stefan Beller
0 siblings, 1 reply; 5+ messages in thread
From: Phil Susi @ 2016-03-15 17:27 UTC (permalink / raw)
To: git
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: git checkout --theirs fails
2016-03-15 17:27 git checkout --theirs fails Phil Susi
@ 2016-03-15 21:35 ` Stefan Beller
2016-03-15 21:47 ` Junio C Hamano
0 siblings, 1 reply; 5+ messages in thread
From: Stefan Beller @ 2016-03-15 21:35 UTC (permalink / raw)
To: Phil Susi; +Cc: git
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
>
> --
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: git checkout --theirs fails
2016-03-15 21:35 ` Stefan Beller
@ 2016-03-15 21:47 ` Junio C Hamano
2016-03-16 12:45 ` Phil Susi
0 siblings, 1 reply; 5+ messages in thread
From: Junio C Hamano @ 2016-03-15 21:47 UTC (permalink / raw)
To: Stefan Beller; +Cc: Phil Susi, git
Stefan Beller <sbeller@google.com> writes:
> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: git checkout --theirs fails
2016-03-15 21:47 ` Junio C Hamano
@ 2016-03-16 12:45 ` Phil Susi
2016-03-16 21:12 ` Jeff King
0 siblings, 1 reply; 5+ messages in thread
From: Phil Susi @ 2016-03-16 12:45 UTC (permalink / raw)
To: Junio C Hamano, Stefan Beller; +Cc: git
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?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: git checkout --theirs fails
2016-03-16 12:45 ` Phil Susi
@ 2016-03-16 21:12 ` Jeff King
0 siblings, 0 replies; 5+ messages in thread
From: Jeff King @ 2016-03-16 21:12 UTC (permalink / raw)
To: Phil Susi; +Cc: Junio C Hamano, Stefan Beller, git
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-03-16 21:13 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-15 17:27 git checkout --theirs fails Phil Susi
2016-03-15 21:35 ` Stefan Beller
2016-03-15 21:47 ` Junio C Hamano
2016-03-16 12:45 ` Phil Susi
2016-03-16 21:12 ` Jeff King
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.