On Fri, Nov 22, 2013 at 10:47 PM, Sohail Somani
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; 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; Unfortunately I can't check if all these steps works right now but will do it in a bit more than a week.