Hi, I was going to respond, but this covered most of what I was going to say. One minor addition: Klaim - Joël Lamotte wrote:
Sohail Somani wrote:
Thanks, but how would you share this repo with the rest of your team members? At the very least, build machines. They would not be very amenable to cloning a repo from dev machines. In this case, you'd need to fork the boostorg/boost repo, correct?
You should fork
A. the super repository. boostorg/boost, which will give you a way to modify which submodules are used; B. the specific library Fork them either on github or in a place available to your team, as long as they can access it it's fine.
Then locally: 1. clone your boost super fork; 2. in this clone, change the address of the submodule you want to use your own library fork with;
Just to clarify this step, since the other urls in the .gitmodules file are relative, you'll need to make them absolute and point them to the boostorg ones (unless you want to fork *all* the boostorg repos).
3. this is a change, commit it, then push it up to your fork; 4. now your boost super repo fork is pointing to your sub library fork as a submodule, instead of the official repository of this library; 5. this one I'm not sure is necessary: now pull from your fork and make sure your local version is using the right submodule address (to your library fork); 6. each time you want to upgrade any of these forks, you'll need to pull from the original repositories and then merge with your changes; 7. if the forks are on github, indeed you can easily submit pull requests but still continue with your version if it's not accepted yet or ever;
With that, I think it should work, though I'll also be unable to test for a couple days. Thanks, Nate