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