Johannes Schindelin <johannes.schinde...@gmx.de> writes:
>> I don't think its possible to guess the semantics of the original merge
>> as users can use custom merge strategies and amend the result. It would
>> be possible to detect and unamended '-s ours' merge but special casing
>> that may end up causing users more confusion rather than helping them.
> FWIW I agree.
I think it is a mistake to sacrifice predictability only to add
cleverness that sometimes work. Elsewhere in the thread, I think I
saw an argument to treat interactive and non-interactive something
very different, but there is no fundamental difference between them
(it is far easier with interactive to force the command to "port"
each change to a vastly different context) so having consistent
behaviour between the two cases is important, too.
> My original plan was to always merge recursively and suggest to use `exec`
> commands if anything else is needed.
> But now with that excellent new idea to perform successive three-way
> merges of the original merge commit with the new tips, using the old tips
> as merge base, I am considering to change that.
OK, does this mean we want to wait before merging the "recreate
merge" topic down to 'next'? For more than a few weeks, it has been
slated for 'next'.