Re: Unexpected or wrong ff, no-ff and ff-only behaviour

From: Sergey Organov <sorganov@gmail.com>
Date: Jul 11, 2019, 05:13 UTC
Message-ID: <87sgrdf91j.fsf@osv.gnss.ru>
In-Reply-To: <xmqqtvbtu9uo.fsf@gitster-ct.c.googlers.com>

Junio C Hamano <gitster@pobox.com> writes:

[...]

> The "the tip being merged into the mainline must always be
> fast-forwardable",

It's rather "the tip being merged into the mainline must be fast-forwardable the first time it is merged".

Show 7 quoted lines

> however, is not consistent with the topic branch workflow, and I do
> not mean this in the sense that you should never rebase just before
> submitting (which is a bad practice). For an initial merge of the
> topic to the mainline, the project can keep rebasing to the
> then-current tip of the mainline, and as long as they can afford the
> cycle to test the result, "record the range of the topic branch by
> making a redundant merge" would work.

Yes, that's exactly it, and, as the rule holds for the first topic merge only, the rest of workflow is as usual, no drastic changes.

Overall, it only ensures the first merge of the topic is semantically simpler, nothing more.

-- Sergey