Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. -- 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