Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20221231/09242d97/attachment.sig>