Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
7 tasks
davidak opened this issue Jan 26, 2019 · 6 comments · Fixed by #16582
Closed
7 tasks

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

davidak opened this issue Jan 26, 2019 · 6 comments · Fixed by #16582
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first.

Comments

@davidak
Copy link

davidak commented 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 #4052, requested in #3844.

@lunny lunny added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label Feb 7, 2019
@qwertfisch
Copy link

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
Copy link

@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
Copy link
Contributor

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

@aaribaud
Copy link
Contributor

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
Copy link
Contributor

@aaribaud would you like to propose a PR?

@aaribaud
Copy link
Contributor

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 added a commit to aaribaud/gitea that referenced this issue Jul 30, 2021
Reword options making clear whether the PRed branch is rebased or not, and which type of commit will be created if any.
zeripath pushed a commit that referenced this issue Aug 2, 2021
Reword options making clear whether the PRed branch is rebased or not, and which type of commit will be created if any.
AbdulrhmnGhanem pushed a commit to kitspace/gitea that referenced this issue Aug 10, 2021
Reword options making clear whether the PRed branch is rebased or not, and which type of commit will be created if any.
@go-gitea go-gitea locked and limited conversation to collaborators Oct 19, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants