Boost logo

Boost :

Subject: Re: [boost] Post-git forking process
From: Sohail Somani (sohail_at_[hidden])
Date: 2013-11-22 16:47:50


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_at_[hidden]: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?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk