Change name of "Rebase and Merge (--no-ff)" merge style to more meaningful one

[davidak]

• Gitea version (or commit ref): 1.7
• Git version:
• Operating system:
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

Having command line options, like --no-ff as description of a button is not really meaningful to many people and is bad usability.

Please try to find a meaningful name and maybe document the options, if it's not 100% clear for every user what it does.

https://docs.gitea.io/en-us/pull-request/

Added in #4052, requested in #3844.

[qwertfisch]

Without experience in pull requests (though working in teams using Git for years), I stumbled over this option and had to research a bit to get information about what merge strategy would be used. Despite knowing about merge commits, fast-forward and rebasing, I wasn’t sure, even after reading the according request feature.

The Azure Devops Team has a blog article describing all four merge styles with a description, a small animation and a paragraph explaining the reason for any style.

The last one is called Semi-linear merge there. This sounds more descriptive and would be my proposal for a name change.

[edgar-bonet]

@qwertfisch wrote:

[Rebase and Merge (--no-ff)] is called Semi-linear merge there. This sounds more descriptive [...]

I disagree. “Semi-linear merge” is not standard terminology. No one knows what that means unless they use Azure Repos or have just read that blog article.

On the other hand, the article shows the Azure Repos merge type selection menu, which displays, below each option, a lengthier description of what it means. This is a very nice feature that helps clarify the ambiguous names. We also see the “Limit merge types” configuration GUI which uses names that are, in my opinion, very clear:

• “Merge Pull Request” is called there “Basic merge (no fast-forward)”
• “Squash and Merge” is “Squash merge”
• “Rebase and Merge” is “Rebase and fast-forward”
• “Rebase and Merge (--no-ff)” is “Rebase with merge commit”

My personal suggestion would be:

• “Merge Pull Request” → “Create merge commit”
• “Squash and Merge” → “Squash and fast-forward”
• “Rebase and Merge” → “Rebase and fast-forward”
• “Rebase and Merge (--no-ff)” → “Rebase and create merge commit”

Rationale: every merge type ends up either creating a merge commit or fast-forwarding the base branch, so better be explicit.

[tgurr]

Just want to add my 2 cents here since I also got quite confused on how to properly setup the options, maybe it's also the localization kicking in making this even more confusing but upon using google to search for how to enable Fast-forward merges
I came across the gitlab documentation: https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html and it's kind of hard to figure out how to configure Gitea to achieve the same Fast-forward merge without a merge commit and only allow that without trial and error. Maybe consider adding a (--ff-only) hint like there already is with (--no-ff) would make things more clear. Having additional longer descriptions below each option like already mentioned above would be nice as well.

Additionally it would be nice as well to have some kind of documentation like the gitlab one mentioned above, currently I was unable to find something useful on https://docs.gitea.io/en-us/ as it seems to center more or less exclusively on editing the central configuration file of gitea than on the various gui options.

[aaribaud]

Stumbling on this thread while searching for the meaning of the gitea merge strategies, I would like to mention that the so-called the "squash merge" isn't actually a merge, and the name is thus slightly misleading; I would avoid using the "merge" word for this one. Also, being a sucker for concision, I'd say "then" rather than "and", to underline the order of actions. therefore, I would personally go for :

• “Merge Pull Request” → “Create merge commit”
• “Squash and Merge” → “Create squash commit”
• “Rebase and Merge” → “Rebase then fast-forward" (1)
• "Rebase and Merge (--no-ff)” → “Rebase then create merge commit”

(1) or maybe even "Rebase then append", which is arguably simpler to grasp but less close to the terminology.

[zeripath]

@aaribaud would you like to propose a PR?

[aaribaud]

Happy to. For the "Rebase and Merge" case, I'll go with "Rebase then fast-forward" wording unless someone screams at me for it.