Sure, but that is true about absolute majority of C* codebase. Most of our utility classes are the same in most branches, without changing that much. It’s not a reason enough to pull everything into a submodule.
At the end of the day I would rather deal with plain old C* repo branches, then the combination of jamm repo branches, plus a submodule, plus pointers to different jamm branches in C* branches. Forward merging and backward-porting code is something we are pretty good at. > On 7 Jan 2026, at 20:16, Doug Rohrer <[email protected]> wrote: > > The last part here is a really good point. Given it'll be something that we > need in multiple branches, using a submodule may well be the better option. > > Copy/paste of changes across several Cassandra branches is, as we all know, > pretty painful. > > Doug > >> On Jan 7, 2026, at 7:38 AM, Mick <[email protected]> wrote: >> >> >> >>> On 6 Jan 2026, at 18:12, Josh McKenzie <[email protected]> wrote: >>> >>>> While your solution is the easiest one, undeniably, of course, it >>>> seems to disregard the existing user base. Some of them are other >>>> Apache projects too. I think that we are beyond this and we want to >>>> have it re-usable by other projects too. >>> >>> Right now we're a pure consumer of the lib. If we brought it in-tree and >>> published artifacts from our source, we'd be becoming maintainers of the >>> lib which is a Big Change. >>> >>> I don't think we're ready to sign up for that tbh and I'm weakly against it. >>> >>> So that leaves a) copying code in-tree, or b) submodule. >> >> >> >> Right, if we're not taking over jamm then we're not needing to maintain it >> as a separate code repo. (I didn't realise this was the intention either.) >> >> Aside from that, a git submodule does have a benefit due to how we can >> change the branch of it we use and how we need to do that we it comes time >> to back-porting jdk support to earlier versions. I don't have an opinion >> here, it's just another point of consideration. >
