Replace merge with rebase for cleaner history

[samyuh]

I'm suggesting to use rebase instead of merge when incorporating changes from one branch to another.

Rebase helps maintain a cleaner, linear commit history by replaying the commits from the current branch on top of the target branch. This approach avoids the creation of unnecessary merge commits and ensures a more streamlined history, making it easier to track changes and manage the repository.

To achieve this, it's only necessary to change one config in the repository settings.

[minrk]

Thanks for the suggestion, but merge commits serve a useful purpose and make the changes from a PR clearer, and better represent the reality of development, and I think it is super important to avoid asking contributors to 'clean up' their history in PRs, which rebased linear history encourages. Rebasing during review should generally be discouraged, because it makes tracking changes since last review much more challenging.

A combination of merge (most of the time) and squash & merge (only where history has grown significantly out-of proportion to the change) is generally what we follow and offers the best balance of history and contributor support.

[samyuh]

Thank you for your insight. I'm more used to rebase and squashing, and I always thought it provided advantages over merge requests. However, after your explanation, I see it's really a tradeoff, and in this case, I now consider merge requests to be valuable for open-source projects like this.

[minrk]

Thanks! Yeah, it's always tricky with trade-offs, there's definitely not just one right answer.