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

[Junio C Hamano <gitster@pobox.com>]

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

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

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