> > … extrapolating this experience to multiple C* versions > > To include forward-merging, bisecting old history, etc etc. that's a leap of faith that I believe deserves the discussion.
- patches are off submodule SHAs, not the submodule's HEAD, > > > A SHA would point to the HEAD of a given branch, at the time of merge, > just by SHA? I’ve no idea what you imagine here, but this just ensures that > a given SHA of the importing project continues to compile correctly when it > is no longer HEAD. It does not mean there’s no HEAD that corresponds > directly to the SHA of the importing project’s HEAD. > That wasn't my concern. Rather that you need to know in advance when the SHA is not HEAD. You can't commit off a past SHA. Once you find out (and how does this happen?) that the submodule code is not HEAD what do you then do? What if fast-forwarding the submodule to HEAD's SHA breaks things, do you now have to fix that or introduce branching in the submodule? If the submodule doesn't have releases, is it doing versioning, and if not how are branches distinguished? Arn't these all fair enquiries to raise? - you need to be making commits to all branches (and forward merging) > anyway to update submodule SHAs, > > > Exactly as you would any library upgrade? > Correct. submodules does not solve/remove the need to commit to multiple branches and forward merge. Furthermore submodules means at least one additional commit, and possibly twice as many commits. - 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), > > > If you do feature development against Accord then you will obviously > branch it? You would only make bug fixes to a bug fix branch. I’m not sure > what you think is wrong here. > That's not obvious, you stated that a goal was to avoid maintaining multiple branches. Sure there's benefits to a lazy branching approach, but it contradicts your initial motivations and introduces methodology changes that are worth pointing out. What happens when there are multiple consumers of Accord, and (like the situation we face with jamm) its HEAD is well in front of anything C* is using. As Henrik states, the underlying problem doesn't change, we're just choosing between trade-offs. My concern is that we're not even doing a very good job of choosing between the trade-offs. Based on past experiences with submodules: that started with great excitement and led to tears and frustration after a few years; I'm only pushing for a more thorough discussion and proposal.
