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

From: Sergey Organov <sorganov@gmail.com>
Date: Mar 28, 2018, 05:57 UTC
Message-ID: <874ll0d9nt.fsf@javad.com>
In-Reply-To: <nycvar.QRO.7.76.6.1803271536020.77@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>

Hi Johannes,

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

> Hi Sergey,
>

[...]

Show 16 quoted lines

>> >> Reusing existing concepts where possible doesn`t have this problem.
>> >
>> > Existing concepts are great. As long as they fit the requirements of
>> > the new scenarios. In this case, `pick` does *not* fit the requirement
>> > of "rebase a merge commit".
>> 
>> It does, provided you use suitable syntax.
>
> You know what `pick` would also do, provided you use suitable syntax? Pick
> your nose.
>
> Don't blame me for this ridiculous turn the discussion took.
>
> Of course, using the suitable syntax you can do anything. Unless there is
> *already* a syntax and you cannot break it for backwards-compatibility
> reasons, as is the case here.

Backward compatibility to what? To a broken '--preserve-merges'? I had a feel you've invented '--recreate-merges' exactly to break that compatibility. No?

Or is it "Backwards compatibility of a feature that existed only as a topic branch in `next` before being worked on more?", as you say yourself below?

[...]

Show 12 quoted lines

>> > The implementation detail is, of course, that I will introduce this with
>> > the technically-simpler strategy: always recreating merge commits with the
>> > recursive strategy. A follow-up patch series will add support for rebasing
>> > merge commits, and then use it by default.
>> 
>> Switching to use it by default would be backward incompatible again? Yet
>> another option to obsolete? Sigh. 
>
> Oh wow.
>
> Backwards compatibility of a feature that existed only as a topic branch
> in `next` before being worked on more? Any other splendid ideas?

Either you care about compatibility or not. You can't have it both ways, sorry.

And "technically-simpler strategy: always recreating merge commits with the recursive strategy" vs. "rebasing merge commits" is not just a minor strategy change, it's entire paradigm shift in handling merge commits while rebasing. I'm afraid you will still come up with a wrong design unless you finally accept this fact.

-- Sergey