Boost logo

Boost-Build :

Subject: Re: [Boost-build] What is the proper workflow to fork library, test, and pull request?
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-05-25 20:15:28


On 5/25/2017 1:10 PM, Tal Lancaster via Boost-build wrote:
>
>> On May 25, 2017, at 12:06 PM, Steven Watanabe via Boost-build <boost-build_at_[hidden]> wrote:
>>
>> AMDG
>>
>> On 05/25/2017 10:46 AM, Tal Lancaster via Boost-build wrote:
>>> What is the expected workflow to be able to fork a library, build and test it, and then do a pull request against my changes? Is this written up anywhere? So far I haven’t stumbled across it.
>>>
>>> I am familiar how to do this for a normal GitHub repository. But I have run into a number of false starts.
>>>
>>> Forked date_time, but I was manually building it and a few of its tests.
>>> cloned the boost super repo (which did give me everything). But it isn’t a fork.
>>> Forked boost super repo and cloned forked repo (as I would in a normal project). But it is missing almost everything.
>>>
>>> Steven has pointed out how to go about testing part. So I think the missing piece is what is the proper way to clone so I will have what I need to be able to build and test a particular library and then perform a pull request?
>>>
>>
>> - clone the superproject
>> - fork date_time
>> - checkout your fork of date_time inside
>> the date_time submodule of the superproject.
>>
>
> Ah, so I just replace the superproject’s date_time with the forked clone. Got it.

Yes.

After you finish testing your local changes and commit them locally,
push your result to the forked clone. Then if you have not already made
a pull request, bring up your forked project in Github and just click
the 'New pull request' button. Once you have made a pull request, any
further changes you push to your forked clone becomes part of that pull
request.

>
> Thanks.
>
> Tal


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk