On Fri, Nov 22, 2013 at 10:47 PM, Sohail Somani <sohail@taggedtype.net>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; 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.