On 2022-12-31 18:34:02 +0100 (+0100), Jakob Meng wrote: [...]
Without a rebase, a new (additional) merge commit will be created. Merge commits vs rebases is a controversial topic, both have their pros and cons [1][2]. For Ansible OpenStack collection, I prefer to rebase each patch, esp. before +w'ing it, to get a flat and readable history. This helps me with keeping track of what has to be backported from master branch to stable/1.0.0 branch. YMMV. 😉 [...]
I suppose my experience is clouded by working on projects like OpenStack where you have multiple reviewers approving changes in the same repositories and merge-time testing, so no guarantees that the resulting commits will be fast-forward merges unless you explicitly serialize them (effectively abandoning the benefits of Zuul's parallel gating). Outside OpenStack, I agree that some people get weird about merge commits and consider them "unclean" or somehow complicating bisection (they don't necessarily but that's another story). For OpenStack and other projects relying on OpenDev's Gerrit and Zuul deployments however, where the merge mechanism is merge-when-necessary, trying to avoid merge commits seems like a lot of pointless effort and tacking into the wind rather than going with the flow. -- Jeremy Stanley