Add Merge Style: Fast-Forward Only (`--ff-only`)

[chrisnc]

Feature Description

For projects that want to enforce a linear history, supporting fast-forward-only in the PR UI is very helpful. This is a similar request to #20769 except hopefully more narrow and easier to implement and explain. Rebase+fast-forward has a number of drawbacks for some workflows that are solved by fast-forward-only: mainly that commit hashes can never be modified, and also that any GPG signatures on the commits will be preserved. (Personally, if I had --ff-only, I would not need the --ff style merge as in #20769; I could choose the --no-ff merge when I don't mind a merge commit, or sync and merge --ff-only if I don't want one.)

For other background of why this is useful, here is a discussion about the same request for GitHub PRs: https://github.com/orgs/community/discussions/4618

I have a first attempt at an implementation to get a feel for how it would work, but I wanted to get feedback on the idea first before requesting review of that.

[metbosch]

In our organization, we will be very happy with that feature. The rebase & fast-forward has several drawbacks if some merge commit was made in the PR commits by any member.

My opinion is that the fast-forward (only) option should replace the current rebase & fast-forward. The rebase part of this option can be achieved by the update (by rebase strategy) button. This button appears in the PR view when the code is not on top of target branch.

[chrisnc]

I think those two merge strategies would continue to co-exist. The rebase + fast-forward in one click is convenient for projects where that strategy is desired.

[harmathy]

»Rebase then fast-forward« is already the equivalent of --ff-only. Well in practice it is

git merge --ff-only || git rebase

But what is discussed in https://github.com/orgs/community/discussions/4618 is about support of the equivalent of --ff, which is exactly what I proposed for gitea in #20769.

[chrisnc]

If you read the description and replies of that GitHub community issue, it's clear that the OP is talking about "fast-forward only" (they do not want merge commits), and the discussion is about the drawbacks of using rebase-and-merge, which is the currently available merge strategy that avoids merge commits on GitHub. The title is misleading. It becomes clear if you replace "--ff" with "fast-forward" in the title. They may not be aware of the fallback behavior of the --ff flag or that it is the default behavior of git merge, because they wrote:

If we have an option to only allow merges of PRs with --ff, we will keep the commit hashes while not having a new merge commit.

Regardless, I think both --ff and --ff-only are valid to support, and one does not obviate the other really. For the way I use git though, --ff-only is what I want, which is why I opened this.

[theoparis]

I would also like to see this added as this is the only blocker preventing me from switching to gitea over gitlab. Gitlab currently uses a lot more RAM which is unfortunate.

[sebthom]

This is one of the top requested features for GitHub. Implementing this would really set Gitea apart. All the reasons why this is extremely useful (like signed commits + linear git history) can be found here https://github.com/orgs/community/discussions/4618

[delvh]

To summarize what I've seen so far:

• There seems to be little harm in offering it,
• it most likely won't require a lot of maintainence
• it brings some benefits, especially regarding repo security
• there seems to be interest in using this feature.

As far as I'm concerned, this means the proposal is accepted.
If anyone is willing to open a PR, please go ahead.

[delvh]

Although, on second thought, I do have an implementation question:
This most likely affects two places, right?

1. The merge box of a PR
2. The repo settings to enable/disable these merges

Both would need to be added by a proposed PR.
Or did I miss any other change that needs to be done?

[chrisnc]

Great! I've rebased the implementation I mentioned in the initial post here and resolved conflicts and made sure it builds, and submitted it as a draft (#28954). I think the two items you mention are the main changes needed for this, though I could be forgetting something myself. I'll continue discussion on the PR.