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

New Issue

GiteaMirror · 2025-11-02T04:49:39-06:00

GiteaMirror commented

2025-11-02 04:49:39 -06:00

Originally created by @davidak on GitHub (Jan 26, 2019).

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 https://github.com/go-gitea/gitea/pull/4052, requested in https://github.com/go-gitea/gitea/issues/3844.

Originally created by @davidak on GitHub (Jan 26, 2019). - 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 https://github.com/go-gitea/gitea/pull/4052, requested in https://github.com/go-gitea/gitea/issues/3844.

GiteaMirror added the type/proposal label 2025-11-02 04:49:39 -06:00

GiteaMirror closed this issue

2025-11-02 04:49:39 -06:00

GiteaMirror commented

2025-11-02 04:49:39 -06:00

@qwertfisch commented on GitHub (Jun 16, 2020):

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.

@qwertfisch commented on GitHub (Jun 16, 2020): 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](https://devblogs.microsoft.com/devops/pull-requests-with-rebase/) 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.

GiteaMirror commented

2025-11-02 04:49:40 -06:00

@edgar-bonet commented on GitHub (Jun 23, 2020):

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

@edgar-bonet commented on GitHub (Jun 23, 2020): @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.

GiteaMirror commented

2025-11-02 04:49:40 -06:00

@tgurr commented on GitHub (Mar 3, 2021):

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.

@tgurr commented on GitHub (Mar 3, 2021): 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.

GiteaMirror commented

2025-11-02 04:49:40 -06:00

@aaribaud commented on GitHub (Jul 30, 2021):

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.

@aaribaud commented on GitHub (Jul 30, 2021): 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.

GiteaMirror commented

2025-11-02 04:49:40 -06:00

@zeripath commented on GitHub (Jul 30, 2021):

@aaribaud would you like to propose a PR?

@zeripath commented on GitHub (Jul 30, 2021): @aaribaud would you like to propose a PR?

GiteaMirror commented

2025-11-02 04:49:40 -06:00

@aaribaud commented on GitHub (Jul 30, 2021):

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

@aaribaud commented on GitHub (Jul 30, 2021): Happy to. For the "Rebase and Merge" case, I'll go with "Rebase then fast-forward" wording unless someone screams at me for it.

GiteaMirror referenced this issue

2025-11-02 12:14:40 -06:00

[PR #2822] [MERGED] Fix update-translations on drone #16613

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#2822