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

From: Sergey Organov <sorganov@gmail.com>
Date: Mar 30, 2018, 12:36 UTC
Message-ID: <87bmf5zqn3.fsf@javad.com>
In-Reply-To: <nycvar.QRO.7.76.6.1803301235560.5026@qfpub.tvgsbejvaqbjf.bet>

Hi Johannes,

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

Show 25 quoted lines

> Hi,
>
> On Thu, 29 Mar 2018, Sergey Organov wrote:
>
>> Jacob Keller <jacob.keller@gmail.com> writes:
>> 
>> > I care about the general compatibility of the rebase todo list
>> > regardless of which options you enabled on the command line to
>> > generate it.
>> 
>> It's a good thing in general, yes. However, I recall I was told by the
>> author that --recreate-merges was introduced exactly to break backward
>> compatibility of the todo list. If so, could we please agree to stop
>> using backward compatibility as an objection in the discussion of this
>> particular feature?
>
> That is a serious misrepresentation of what I said.
>
> If I had changed --preserve-merges to the new format, *that* would have
> broken backwards-compatibility.
>
> So the entire reason of introducing --recreate-merges was to *not have to
> break backwards-compatibility*.
>
> I definitely did not say the *exact opposite*.

I'm sorry I committed ambiguity in my wording that allowed it to be misinterpreted. I actually intended to say roughly the same thing you are saying, as what matters for the discussion is that new todo list format does not need to be (backward-)compatible to that of --preserve-merges.

> Hopefully this clarifies your confusion,

There was actually no confusion on my side, and I like your wording better.

Except that you've managed to clarify your intentions without actually addressing the primary concern:

Could we please agree to stop using backward compatibility as an objection in the discussion of the --recreate-merges feature?

Could we?

I understand you are still resistant to change 'pick' syntax, but it's not because of backward-compatibility, right?

-- Sergey