PR Code Suggestions ✨

No code suggestions found for the PR.

@PeterDaveHello Hey, I recommend using rebase when merging PRs with simple, clear commits. For PRs with many commits but all related to the continuous development of a single feature, use squash merge. Regular merge can significantly clutter the commit history and make it harder to read, so try to avoid it.

@josStorer Thanks for the feedback on the merge strategy!

Totally understand the preference for rebase/squash to keep history clean. For simple changes like this namespace update, rebase would definitely work well.

The merge approach here preserves the atomic development context. Squash can sometimes make it harder to trace back specific changes when debugging or doing code archaeology later, especially when multiple logical changes get combined. For smaller projects like this, regular merges stay manageable when branches are kept focused and up-to-date.

But I'm curious about your experience! Have you found that merge commits create real issues in this project's workflow? I'm definitely open to adjusting my approach based on what works best for the project.

Should I default to rebase for single-commit changes like this going forward? Happy to follow whatever strategy fits the project best! 😊

@PeterDaveHello

Should I default to rebase for single-commit changes like this going forward? Happy to follow whatever strategy fits the project best! 😊

Yes, I recommend rebasing this kind of changes.

Regarding squash merges: since this is an open-source project on GitHub, when you need to trace a change you can simply open the corresponding PR. A squash merge automatically includes the PR’s issue number, so trace back is simple. In this context a squash merge does not break traceability; instead, it keeps the history clean and makes it easier for developers to review, while the PR itself retains the full commit log, discussion, and linked issues—far richer information than what Git alone provides.

Keeping the branch’s individual commits in the main history adds no value. A regular merge message ("Merge pull request #xxx from xxx/yyy") tells you nothing about what was changed unless you open the branch again.

A well-formed PR should focus on a single feature; it can then be squashed into one concise commit. When I’m doing a selection git log review, I can instantly tell where that feature came from and what it did (I do this often).

With a regular merge, developers have to waste time digging through the branch’s history or jumping to the PR page to understand what the merge actually did—yet those individual commits are usually meaningless. If the changes are meaningful and atomic, use rebase-merge; if the PR is so large or complex that it touches many modules, it should be split into smaller PRs or landed directly by maintainers.

In short, regular merge does preserve every single commit and keeps it traceable, but in practice that benefit is outweighed by the noise it adds. The PR page already provides full context, and we already adopt different strategies (rebase, squash) based on the nature of the change. Regular merge therefore gives little real-world value and actively hampers history review and debugging—operations I perform frequently. So I don’t think we should use it.

Besides, every PR is tested locally (or should be tested by QA) before it lands, so preserving the entire branch history for future reviews is a very low-frequency need. If a bug related to some merge is really hard to position and fix, the squash-merge message still lets you jump straight to the PR page for the full story.