Add Merge Style: Fast-Forward if possible, Merge Commit if necessary

[harmathy]

Feature Description

• In order to keep history clean, I would like to avoid unnecessary merge commits.
• Rebase is a potentially destructive operation, which may lead to unnecessary conflicts.

Therefore I would like to have a merge style, which conducts a fast-forward merge if possible and created a merge commit if necessary (i.e. diverged target branch).

This would correspond to git merge --ff. Ref. git-merge(1):

       --ff
           With --ff, when possible resolve the merge as a fast-forward (only
           update the branch pointer to match the merged branch; do not create
           a merge commit). When not possible (when the merged-in history is
           not a descendant of the current history), create a merge commit.

Screenshots

No response

[wolftune]

What about the option of fast-forward if possible, but otherwise prompt the user to confirm that they want merge with a merge-request? In other words, for those who think they can fast-forward, don't surprise them with a merge-commit. Instead, tell them that fast-forward isn't available, and have them decide whether to cancel the merge or go ahead with merge-commit.

So, git merge --ff-only basically

[harmathy]

What about the option of fast-forward if possible, but otherwise prompt the user to confirm that they want merge with a merge-request? In other words, for those who think they can fast-forward, don't surprise them with a merge-commit. Instead, tell them that fast-forward isn't available, and have them decide whether to cancel the merge or go ahead with merge-commit.

I would have no problem with such a feature, if it isn't the default. I mean, in general, there is nothing wrong with merge commits.

So, git merge --ff-only basically

That is already implemented as »Rebase then fast-forward«. This means, that you have to either

• merge the target branch locally and push back to the feature branch (which could be an endless job for fast moving target branch) or
• rebase onto the target branch, which is a potentially destructive operation (It can lead to removal of previous merge commits and therefore re-introduce conflicts, which have already been resolved. It also brakes any other branch descending from that feature branch).

[wolftune]

So, git merge --ff-only basically

That is already implemented as »Rebase then fast-forward«

I don't quite follow. is "Rebase then fast-forward" a name for having the user separately do a rebase and then Gitea runs git merge --ff-only?? So, a button setting "Rebase then fast-forward" doesn't cause GItea to run a rebase somehow?

I honestly was hesitant about that setting because there are situations where there's no rebase needed. I guess it's just a label issue. The setting could be called "fast-forward-only (note: you'll need to rebase first if FF isn't possible)" or something like that. Is that what it actually means? The "rebase" part of "rebase then…" means "you might need to do a rebase first"?

[heroofhyla]

So, git merge --ff-only basically

That is already implemented as »Rebase then fast-forward«.

This works as expected if the history between the source and target is linear. But as far as I can tell there is currently no way in the gitea UI to fast-forward merge a branch if the branch already contains a merge commit in it.

For example, in a situation like this:

... trunk is currently at 5f04b8cd60, after doing a "rebase then fast-forward", which was smart enough to fast-forward-only since history was linear.

But if I want to get trunk fast-forwarded from there to the merge commit at 173f8cb971, I find myself needing to use the terminal. It's very simple, just git merge --ff-only develop-b.

I would expect "rebase then fast-forward" to be smart enough to realize that since the current trunk is already an ancestor to 173f8cb971, it can just fast-forward without making any other changes. But instead it rebases all the commits except for the merge commit, like this: