Johannes Schindelin:
Sounds like it should be called "theirs", then.
Why should it be called "theirs" when it takes "ours"?
Because it took "their" (= upstream) tree, not "our" (= local branch) tree.
Seems to me the name is a bit confusing in the case of a rebase, as I am
"merging" my changes *onto* the upstream, not the other way round as would
be the case with a regular merge.
Note: the thing I think Thomas wanted to clarify is that this strategy
does not _resolve conflicts_ to "our" version, but it just outright
ignores "theirs". IOW, after a merge with the "ours" strategy,
"HEAD^{tree}" and "HEAD^^{tree}" will point to _exactly the same object_.
And in the case of a rebase, the other way around: With --rebase
--strategy=ours, I am basically asking to throw all my local commits away?
If you want to use any merge strategy, you must understand what it does
first. There is no way around that. No change in UI, or in the core code
of Git, can relieve you of this obligation.
No, that is why I recommended that what needed clarification was the
documentation. I read the documentation of "ours":
"This resolves any number of heads, but the result of the merge is
always the current branch head. It is meant to be used to
supersede old development history of side branches."
and thought that it meant that it
a) could resolve a merge conflict, no matter the number of branches involved
("resolves any number of heads").
b) would replace any merge conflict with the contents in the current
repository's branch ("result of the merge is always the current branch head").
Apparently, the "used to supersede old development history" means that it
actually throws the entire contents of one of the branches out, which is not
what I wanted. I didn't understand that from the documentation, however.
--
\\// Peter - http://www.softwolves.pp.se/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html