Re: [PATCH 3/3] rebase: refuse to rebase with -s ours

Johannes Schindelin [off-list ref] writes:

I meant the following: if "rebase -s ours" refuses to run, but my boss has 
written this cunning merge strategy "superduper" which is equally unlikely 
to yield a sensible result, "rebase -s superduper" should still refuse to 
run, no?

Why should it?

Now, this scenario might be too rare to take care of, but maybe it shows 
that we have a design flaw here?

The decision is up to the user who is much more familiar with such a
custom 'superduper' strategy, and git itself is in no position to make
that decision for the user.  It is none of our business to forbid users
from using what he wrote, when we do not know what it is.

I do not think the "rarity" is relevant.

What do you mean by a design flaw?  In other words, how should things look
like in your ideal design?

Certainly you are not talking about a design that enforces users who want
to use custom strategy to first submit the strategy implementation to us
for a review and have our blessings (perhaps we digitally sign approved
strategy implementations) before being able to use it in "merge -s" and
"rebase -s".

I can _guess_ what you are _not_ talking about but I cannot tell what you
_are_ talking about; sorry.

Heya,

On Mon, Nov 16, 2009 at 22:45, Junio C Hamano [off-list ref] wrote:

I can _guess_ what you are _not_ talking about but I cannot tell what you
_are_ talking about; sorry.

I would hazard a way for the merge strategy to indicate whether it is
fit to be used as rebase strategy?

-- 
Cheers,

Sverre Rabbelier