On 11/22/2013, 4:39 PM, Nathan Crookston wrote:
Hi guys,
Beman Dawes wrote:
Sohail Somani wrote:
With Git, it should become easier to contribute said patches as well as pull in whichever particular changes I need. However when I attempted such a fork recently, I was a bit lost. As I understood it, the process should have been:
1. Create a fork of https://github.com/boostorg/boost and use this fork in my project
2. Create a fork of the library/libraries I wanted to patch
3. Update the submodules in my boostorg/boost fork to point to my forked libraries
4. Post a pull request for the respective libraries. Once the changes have been accepted, point back to the official boostorg repo
Git experts: Is the approach Sohail outlines above optimal? If not, what would you suggest?
I would do something like the following:
After having retrieved boost, or as much of boost as I needed, I would:
1. Fork that particular repository on GitHub. So, perhaps I'd fork boost.gil. 2. Go to the particular submodule on my local machine and create a branch for my work. For example, I'd go to gil and run: `git checkout -b fix_casts` 3. Make my changes and commit on my branch. 4. Next, I would add my forked repository as one of the remotes for that submodule: `git remote add personal git@github.com:ncrookston/gil.git` 5. Finally, I would push my branch to my personal repo: `git push personal fix_casts` 6. Once on github, I can make the pull request.
This means you don't have to change all your submodules, nor change things back.
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?