Yeah, I positively dislike merge commits, both from a patch preparation perspective and when trying to piece together a class’ history. It can actively obfuscate the impact to the branch being looked at, as well as make it much harder to skim the git log.
I’d vote to modify our merge strategy irregardless of the benefits to CI. The more I think on it, the more I am anyway strongly -1 on having some bifurcated commit process. We should decide on a uniform commit process for the whole project, for all patches, whatever that may be. From: Joshua McKenzie <jmcken...@apache.org> Date: Tuesday, 14 December 2021 at 18:53 To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: Re: [DISCUSS] Releasable trunk and quality > > I like a change originating from just one commit, and having tracking > visible across the branches. This gives you immediate information about > where and how the change was applied without having to go to the jira > ticket (and relying on it being accurate) I have the exact opposite experience right now (though this may be a shortcoming of my env / workflow). When I'm showing annotations in intellij and I see walls of merge commits as commit messages and have to bounce over to a terminal or open the git panel to figure out what actual commit on a different branch contains the minimal commit message pointing to the JIRA to go to the PR and actually finally find out _why_ we did a thing, then dig around to see if we changed the impl inside a merge commit SHA from the original base impl... Well, that is not my favorite. :D All ears on if there's a cleaner way to do the archaeology here. On Tue, Dec 14, 2021 at 1:34 PM Stefan Miklosovic < stefan.mikloso...@instaclustr.com> wrote: > Does somebody else use the git workflow we do as of now in Apache > universe? Are not we quite unique? While I do share the same opinion > Mick has in his last response, I also see the disadvantage in having > the commit history polluted by merges. I am genuinely curious if there > is any other Apache project out there doing things same we do (or did > in the past) and who changed that in one way or the other, plus > reasons behind it. > > On Tue, 14 Dec 2021 at 19:27, Mick Semb Wever <m...@apache.org> wrote: > > > > > > > > > > > > Merge commits aren’t that useful > > > > > > > I keep coming back to this. Arguably the only benefit they offer now is > > > procedurally forcing us to not miss a bugfix on a branch, but given how > > > much we amend many things presently anyway that dilutes that benefit. > > > > > > > > > Doesn't this come down to how you read git history, and for example > > appreciating a change-centric view over branch isolated development? > > I like a change originating from just one commit, and having tracking > > visible across the branches. This gives you immediate information about > > where and how the change was applied without having to go to the jira > > ticket (and relying on it being accurate). Connecting commits on > different > > branches that are developed separately (no merge tracking) is more > > complicated. So yeah, I see value in those merge commits. I'm not against > > trying something new, just would appreciate a bit more exposure to it > > before making a project wide change. Hence, let's not rush it and just > > start first with trunk. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
