On 8 February 2015 at 22:44, John Bytheway wrote:

On 2015-02-06 16:25, Rene Rivera wrote:

...

I've been trying to clean out the pull requests for the boost super-project and I ran into this one https://github.com/boostorg/boost/pull/33. And I don't really know if it makes sense, as I have personally not done a fork of the super-project.

Is it a real problem? Should we change all the sub-project references? If yes, what are the likely impacts on others and existing release processes?

This issue annoyed me when I forked the super project. I'm slightly surprised that the proposed fix works, but if it does, then it seems reasonable and unlikely to break anything that was previously working...

There's no need to change the submodule paths, all you have to do is set the super-project's origin to point to boostorg/boost. The pull request will prevent anyone from using a different location for the submodules.

On 9 February 2015 at 03:01, Rene Rivera wrote:

On Sun, Feb 8, 2015 at 5:20 PM, Daniel James wrote:

...

...

On 2015-02-06 16:25, Rene Rivera wrote:

...

I've been trying to clean out the pull requests for the boost super-project and I ran into this one https://github.com/boostorg/boost/pull/33. And I don't really know if it makes sense, as I have personally not done a fork of the super-project.

Is it a real problem? Should we change all the sub-project references? If yes, what are the likely impacts on others and existing release

On 8 February 2015 at 22:44, John Bytheway wrote: processes?

...

This issue annoyed me when I forked the super project. I'm slightly surprised that the proposed fix works, but if it does, then it seems reasonable and unlikely to break anything that was previously working...

There's no need to change the submodule paths, all you have to do is set the super-project's origin to point to boostorg/boost. The pull request will prevent anyone from using a different location for the submodules.

OK, good to know. But.. How does one do that? And.. Where do we have that documented for users who want to do that?

I don't think we have any documentation either way. We could put something on the wiki, but the chances are most people wouldn't find it. Someone who wants to maintain a fork of the super-project will need to know how to handle remotes, otherwise they'll probably just get in a mess. Git's submodule system is fiddly enough for simple cases. But if you want to write a page, here's the basics: How it's done depends on the software you use. If you use the github command line client, and clone from boostorg then fork using 'hub fork', it will keep 'boostorg' as the 'origin' remote, and your account's remote will be named after your username, which is what's wanted. If not, you can clone from boostorg, then add the fork (untested): git clone https://github.com/boostorg/boost.git git remote add -f danieljames https://github.com/danieljames/boost.git git checkout danieljames/some-branch -b some-branch Or clone from the fork, and then add origin (also untested): git clone -o danieljames -b some-branch https://github.com/danieljames/boost.git git remote add origin https://github.com/boostorg/boost.git If someone wants to publish a fork for others to use without doing this, then they're going to have to mess around with the modules anyway, I don't think it's much work to do a search and replace.