Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 6, 2018, 23:24 UTC
Message-ID: <xmqqzi3k23fu.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <nycvar.QRO.7.76.6.1803061812090.20700@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 6 quoted lines

>> 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.

Show 7 quoted lines

>
> 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'.