On Wed, Nov 1, 2023, at 02:42, Junio C Hamano wrote: > 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). Yes. If you have multiple release/maintenance branches which you need to apply something to then you can’t use this . >> 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. No. The only effect is that you streamline the process of “decide not to use `--no-ff`” since the strategy does it for you. It would act like a small `git my-merge` alias. That is all. -- Kristoffer Haugsbakk
