> > 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.
Having 1/3rd of your commit history be noise and/or things masking changes does more harm than good IMO. On Mon, Dec 13, 2021 at 9:51 AM bened...@apache.org <bened...@apache.org> wrote: > > It makes sense that such bug tickets are incentivised to be minimal, and > if there is a smarter way (improvement) in trunk that is a separate > follow-up ticket and patch > > Are you proposing separating the work entirely, so that we don’t merge up > to trunk at all, or do a no-op merge? Often things are done differently in > trunk (and intervening branches) for a combination of reasons, including > that the landscape has changed so that the earlier approach is > inapplicable. Either way, what you are proposing sounds like introducing > unnecessary additional work? > > > and that we have a more concise git history (one ~third the merge > commits). > > Don’t we get a more concise history with the cherry-pick approach, since > we don’t have any of the merge commits from each prior branch? Today, a > merge commit from 2.2 will accumulate four merge commits on the way to > trunk. > > My view: > > * Merge commits aren’t that useful > * It is a bad idea to have a different CI pipeline for multi-version > development > * It is particularly not worth countenancing solely to retain the > limited utility of merge commits > > > > From: Mick Semb Wever <m...@apache.org> > Date: Sunday, 12 December 2021 at 11:47 > To: dev@cassandra.apache.org <dev@cassandra.apache.org> > Subject: Re: [DISCUSS] Releasable trunk and quality > > I find it cleaner that work is found associated to one sha on the hardest > > > branch, and we treat (or should be) CI holistically across branches. > > > > If we -s ours and amend merge commits on things that straddle stuff like > > 8099, MS rewrite, Simulator, guardrails, etc, then we have multiple SHA > > where the impl for a thing took place and N of them (N being count of > newer > > branches than oldest where it applies) where they're hidden inside a > merge > > commit right? > > > > > That patches can be significantly different across branches is inavertible. > One original commit versus individual commits on each branch is a trade-off > between cleaner git history and github fancies with more direct commits. > Taking it further, patches to release branches should be as minimal as > possible. It makes sense that such bug tickets are incentivised to be > minimal, and if there is a smarter way (improvement) in trunk that is a > separate follow-up ticket and patch. > > So… I am willing to say (for now) that I like it that merge shas have the > connection to the original singular shas on the hardest branch, and that we > have a more concise git history (one ~third the merge commits). > > > > > Also, nothing's keeping us from treating CI holistically and pushing > > --atomic across multiple branches even if we don't have merge commits. > > That's just a procedural question we could agree on and adhere to. > > > > > Sure, but atomic is not the same: it's manual adherence and there's no > history/record of it. >
