Re: [PATCH] merge: --ff-one-only to apply FF if commit is one

From: Kristoffer Haugsbakk <code@khaugsbakk.name>
Date: Oct 31, 2023, 08:32 UTC
Message-ID: <cb166ed4-b8b5-4120-b546-e878445573b6@app.fastmail.com>
In-Reply-To: <xmqq1qdb8wzk.fsf@gitster.g>

On Tue, Oct 31, 2023, at 01:19, Junio C Hamano wrote:

Show 7 quoted lines

> Another more fundamental objection is "Why do we special case only a
> singleton commit?"
>
> Why isn't a trivial two-patch series also OK to fast-forward?
> Three?  There is no inherent reason to draw a line on one commit
> topic---given that a single commit could be a large and involved one
> that could have been a multi commmit series.

I think it’s about the `--first-parent` view. Then you get a one-commit view of each pull request that was merged. For a merge commit it serves as a summary of multiple commits. And a merge commit of one commit would serve as a summary of one commit. So in that case you remove that extra level of indirection.

> And you cannot decide if the "topic" is large enough to deserve a
> binding merge commit even if it is a single commit topic, or if is
> small enough and you want to allow fast-forward, without looking at
> it first.

But the pull request is already given: it either has one commit or several. And you can for sure look at it and either argue that it should be reduced (squashed) to one commit or maybe expanded (split out) into several commits.

The point at which you use such a merge feature is when you are already happy with the pull request (or patch series or whatever else). And then you (according to this strategy) prefer to avoid merge commits for single-commit pull requests.

— —

This is not an argument for making this a built-in strategy. Just an explanation from my vantage point.

-- 
Kristoffer Haugsbakk