> - permanence from a git SHA no longer exists > > With the caveat that I haven't worked w/submodules before and only know > about them from a cursory search, it looks like git-submodule status would > show us the sha for submodules and … >
That isn't one SHA, but a collection of SHAs. I'm thinking about reproducible builds, switching between branches, and git bisecting, this stuff needs to just work. A build that fails fast if a submodule is not on a specific SHA helps but introduces more problems. > we could have parent projects reference specific shas to pull for > submodules to build? > https://git-scm.com/docs/git-submodule/#Documentation/git-submodule.txt-status--cached--recursive--ltpathgt82308203 > <https://urldefense.com/v3/__https://git-scm.com/docs/git-submodule/*Documentation/git-submodule.txt-status--cached--recursive--ltpathgt82308203__;Iw!!PbtH5S7Ebw!e2n2ORCddKzF-g_2-hvb5cz0DzP13WTOV0VhvumHln_OeGIygyswOcGzDw8g3NDm5j5yqWHx8CxQZ7QaQg$> > Yes, we can enforce a 1:1 relationship from parent SHA to submodule SHAs, but then what's the point: you have both the headache of submodules and having to always commit to multiple branches and forward merge. That is, with fixed parent-to-submodule SHA relationships, these new challenges are introduced: - patches are off submodule SHAs, not the submodule's HEAD, - you need to be making commits to all branches (and forward merging) anyway to update submodule SHAs, - if development is active on trunk, and then you need an update on an older branch, you have to accommodate to backporting all those trunk changes (or introduce the same branching in the submodule), IMHO submodules are just trading one set of problems for another. And overall life is simpler if we reduce the cognitive burden to just what we have today: forward merging. Benedict, experience based on developing one feature against one branch doesn't face the problems of working, and switching frequently, between branches. The problem of wanting an external repository for these libraries to promote external non-cassandra consumers I would solve by exporting the code out of cassandra (not trying to import it). Git history is easy to keep/replicate. We were talking about doing this with the jamm library, given its primary development is currently with C* but we want it to appear as a standalone library (/github codebase).
