FWIW, I thought I could link to an example MongoDB commit: https://github.com/mongodb/mongo/commit/dec388494b652488259072cf61fd987af3fa8470
* Fixes start from trunk or whatever is the highest version that includes the bug * It is then cherry picked to each stable version that needs to fix. Above link is an example of such a cherry pick. The original sha is referenced in the commit message. * I found that it makes sense to always cherry pick from the immediate higher version, since if you had to make some changes to the previous commit, they probably need to be in the next one as well. * There are no merge commits. Everything is always cherry picked or rebased to the top of a branch. * Since this was mentioned, MongoDB indeed tracks the cherry picking process explicitly: The original SERVER ticket is closed when fix is committed to trunk branch. However, new BACKPORT tickets are created and linked to the SERVER ticket, one per stable version that will need a cherry-pick. This way backporting the fix is never forgotten, as the team can just track open BACKPRT tickets and work on them to close them. henrik On Tue, Dec 14, 2021 at 8:53 PM Joshua McKenzie <jmcken...@apache.org> wrote: > > > > 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 > > > > > -- Henrik Ingo +358 40 569 7354 <358405697354> [image: Visit us online.] <https://www.datastax.com/> [image: Visit us on Twitter.] <https://twitter.com/DataStaxEng> [image: Visit us on YouTube.] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_channel_UCqA6zOSMpQ55vvguq4Y0jAg&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=bmIfaie9O3fWJAu6lESvWj3HajV4VFwgwgVuKmxKZmE&s=16sY48_kvIb7sRQORknZrr3V8iLTfemFKbMVNZhdwgw&e=> [image: Visit my LinkedIn profile.] <https://www.linkedin.com/in/heingo/>
