Re: [PATCH] Re: Clarify documentation on the "ours" merge strategy.

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 12, 2009, 07:55 UTC
Message-ID: <7vvdhggote.fsf@alter.siamese.dyndns.org>
In-Reply-To: <200911120037.11901.trast@student.ethz.ch>

Thomas Rast <trast@student.ethz.ch> writes:

> Then again, I'm not sure if resolve vs. recursive makes a difference
> in a rebase.  Octopus is weird for a two-head merge, I'm not sure why

...

Show 5 quoted lines

> +	If there is no `-s` option 'git-merge-recursive' is used
> +	instead.  This implies --merge.
> ++
> +Due to the peculiarities of 'git-rebase' (see \--merge above) the only
> +built-in strategy that is actually useful is 'subtree'.

"recursive is just a slower and sometimes buggier alternative to resolve but can handle renames" may mean "people do not have much reason to choose resolve over recursive". But that is quite different from "resolve is not useful here _due to_ the peculiarities of rebase". Wouldn't anybody who thinks "resolve vs. recursive would not make a difference in a rebase" also think "resolve vs. recursive would not make a difference anywhere"?

58634db (rebase: Allow merge strategies to be used when rebasing, 2006-06-21) added "-m" and "-s" to rebase to solve the problem of rebasing against an upstream that has moved files. What the commit actually did was to use recursive (by default) while giving longer rope to the users by choosing other strategies with "-s", without making any judgement as to why other strategies may possibly be useful.

Perhaps there is some different issue at the root of this one. Why would anybody be tempted to say "-s ours" while running a rebase? What did the user want to see it do (instead of being a no-op because "ours" by definition ignores the tree the change is replayed from)?

It is easy to dismiss it as a user misconception and it also is tempting to think that it would be helped with updated description of "ours" to dispel that misconception, but there may be some user wish that is totally different from "ours merge" strategy but still can be validly labelled using a word "ours" by somebody who does not know the way the word "ours" is used in the git land, and satisfying that unknown user wish might be the real solution to this issue.