Git history and merge instead of rebase

[titan73]

Why is OR using merge instead of rebase?

I'm used to Wine project (constant activity of around 10 PRs / 25 commits per day) which uses rebase and history is pretty straightforward to read:
https://gitlab.winehq.org/wine/wine/-/commits/master?ref_type=heads

With merge, history is hard to follow. Commits of a PR are scattered and the PR merge commit is done long after. Moreover, once merge the PR includes non related commits depending on activity between the PR creation and merge.

Is there a particular reason why merge is used instead of rebase?

[QuantamHD]

It's just a choice.

With merge the expected workflow is that you exclusively look at merge commits. So in git log you would just --grep="Merge pull request"

[QuantamHD]

Rebasing has another nasty side effect which is that if anyone ever forks a fork and submits a PR, the stacked changes workflow, rebasing will cause merge conflicts.

[titan73]

Indeed but forking a work repo from someone else is not a very good idea in the long term.

[titan73]

Note that I always use rebase but my question was more from a PR to the main repo. Merge the PR vs rebase the PR and applying commits to the main repo as for Wine.

[maliberty]

There is a more complex workflow for PII developers who work with NDA data. We push to a private repo and then verify the PR is free of sensitive data before making it into a public PR. When the public PR is merged to master and then merged back to the private repo, the private PR is automatically closed by GH. If you rebase then it is no longer recognized as the same and manual management of the private PR/branch is required. More automation could perhaps be applied but that's the reason.