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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 1, 2023, 01:42 UTC
Message-ID: <xmqqa5ryxn8i.fsf@gitster.g>
In-Reply-To: <cb166ed4-b8b5-4120-b546-e878445573b6@app.fastmail.com>

"Kristoffer Haugsbakk" <code@khaugsbakk.name> writes:

Show 5 quoted lines

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

Yeah, I understand that position very well. After all, I was heavily involved in the introduction of the first-parent view to the system at around 0053e902 (git-log --first-parent: show only the first parent log, 2007-03-13). Soon after that, d66424c4 (git-merge: add --ff and --no-ff options, 2007-09-24) added --no-ff to make it easier to maintain the first-parent worldview.

Strictly speaking, the log message on a merge commit serves two purposes, one is to summarize commit(s) on the side branch that gets merged with the merge, and as you said above, it is not needed when merging a topic with just one commit. But the other is to justify why the topic suits the objective of the line of history (which is needed even when merging a single commit topic---imagine a commit that is not incorrect per-se. It may or may not be suitable for the maintenance track, and a merge commit of such a commit into the track can explain if/how the commit being merged is maint-worthy).

A project that does not need the latter can do without a "--no-ff" merge of a single commit topic.

Show 9 quoted lines

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

But that argues against the "--ff-one-only" option, doesn't it?

If you looked at the side branch before you decide to merge it, you know if the topic has only one commit (in which case you decide not to use "--no-ff"), or if the topic consists of multiple commits (in which case you decide to use "--no-ff"). And the only effect to have the "--ff-one-only" option is to allow you *not* to look at what is on the side branch.

Thanks.