Re: [boost] A proposal for superproject structure and testing

On Monday 09 December 2013 19:56:10 Alexander Lamaison wrote:

Andrey Semashev writes:

...

On Monday 09 December 2013 19:29:59 Alexander Lamaison wrote:

...

However, I think the discussion was about a commit already merged to the submodule's master branch, so gc won't touch it.

Not necessarily. In my example a boost release (i.e. a tagged commit to the superproject's master) references a commit in a submodule branch that is neither develop nor master. That branch may never be merged to develop or master.

You mean a special branch quickly made to revert a specific thing before a superproject release but not part of the submodule's mainline development (i.e. develop)?

Yes.

Surely those commits would be merged into the submodule master? After all, they form part of a release, both for the submodule and the superproject.

It didn't look like that from what Peter was suggesting. I'll re-post his example: <quote> Imagine that the submodule has the following sequence of commits: - bug fix - new feature - bug fix - more of new feature - bug fix and the new feature turns out to block the Boost release. Fixing the problem, in your sense, means fixing the new feature so that it becomes Boost-release-worthy. This should indeed be done in develop. Fixing the problem, in my sense, means doing - revert "more of new feature" - revert "new feature" on a branch. </quote> I don't see why such a branch would ever be merged to the main library branches (develop or master), unless the maintainer decides to drop the new features permanently.