Linus doesn’t like how GitHub does merge requests

lore.kernel.org

25 points·tdhz77··4 comments

I have the same feeling regarding both Github and Gitlab merge requests. After using Gerrit for almost 4 years at work with enforced fast-forward, having a linear git log is relaxing.

The merge commits enforced by these "mainstream" platforms are noise for me. I think that now one can choose to fast-forward on pull requests, but per PR and not by default.

Linus isn't really talking about linear history here or forcing devs to rebase. He's just saying that the merge commit's message generated by the UI does not describe the features that were merged and the author of the commit is a gitlhub.com user.

There's no discussion of git strategies here.

I personally prefer merge commit and don't mind having a non linear history.

So Linus is not favouring any type of git strategy or any of that stuff that people like to go on wars about.

The only thing he's saying here is that github pull requests create a merge commit with a non descriptive commit message (only says that two branches where merged, not what was merged) and that the merge commit will be authored by a github.com user.

On gitlab, you can define the commit message of the merge commit and the author will be set to the account that merged the pull request, the only problem with gitlab is that (obviously) the merge commit won't be signed.

Other discussion for same page: https://news.ycombinator.com/item?id=28437734

Reply on news.ycombinator.com