Boost contributing tutorial (GitHub)
Hi, I prepared a tutorial about the contributing at GitHub/Boost describing how to create a Fork of a library, use it inside modular Boost and create a pull request. The tutorial presents examples for Boost.Geometry but could be extended to the other libraries. It has a form of a README of this repository: https://github.com/awulkiew/temp-contributing Would you be so kind and see if everything is ok wth it? In praticular I'd like to hear if this model is good for modular Boost in general? Regards, Adam
On 21/05/2014 9:17 AM, Adam Wulkiewicz wrote:
Hi,
I prepared a tutorial about the contributing at GitHub/Boost describing how to create a Fork of a library, use it inside modular Boost and create a pull request. The tutorial presents examples for Boost.Geometry but could be extended to the other libraries. It has a form of a README of this repository:
https://github.com/awulkiew/temp-contributing
Would you be so kind and see if everything is ok wth it? In praticular I'd like to hear if this model is good for modular Boost in general?
This is a good start from my perspective, thanks for doing it. My selfish question is: how would you recommend maintaining more than one fork of a boost library? Just repeat the process? What about long term for forks that are never merged for whatever reason? Thanks! Sohail
Hi, Sohail Somani wrote:
On 21/05/2014 9:17 AM, Adam Wulkiewicz wrote:
Hi,
I prepared a tutorial about the contributing at GitHub/Boost describing how to create a Fork of a library, use it inside modular Boost and create a pull request. The tutorial presents examples for Boost.Geometry but could be extended to the other libraries. It has a form of a README of this repository:
https://github.com/awulkiew/temp-contributing
Would you be so kind and see if everything is ok wth it? In praticular I'd like to hear if this model is good for modular Boost in general?
This is a good start from my perspective, thanks for doing it.
My selfish question is: how would you recommend maintaining more than one fork of a boost library? Just repeat the process? What about long term for forks that are never merged for whatever reason?
In short, the answer for the first 2 questions is: yes. Basically in Git you can work with as many remotes and branches as you please. Your local branches may be tracking many remote ones, with different names, etc. Just use the "full" form of push/pull git push remote_name branch_name git pull remote_name branch_name or after creating some local branch push it with the -u switch to setup the tracking of the remote. As for the last question, I'm sure it depends on a specific case. But, lets say that you'd like to work in your branch for a long time and periodically update it with the work from the origin repository. In the scenario described in the tutorial you could get the latest version of develop from the origin git checkout develop git pull (the above is the short version of pull which should work if the develop tracked the origin/develop which should be the default case) and then just merge it in your branch git checkout feature/example git merge develop or cherry-pick single commits or whatever. Or you could just merge the origin/develop directly with 'git pull', which is a shorthand for 'fetch' followed by 'merge' (http://git-scm.com/docs/git-pull). It's more Git-related than Boost-related and probably more depends on what do you prefer. I wanted to keep the tutorial simple. Regards, Adam
On 21/05/2014 10:39 AM, Adam Wulkiewicz wrote:
(the above is the short version of pull which should work if the develop tracked the origin/develop which should be the default case) and then just merge it in your branch
git checkout feature/example git merge develop
or cherry-pick single commits or whatever.
Or you could just merge the origin/develop directly with 'git pull', which is a shorthand for 'fetch' followed by 'merge' (http://git-scm.com/docs/git-pull). It's more Git-related than Boost-related and probably more depends on what do you prefer. I wanted to keep the tutorial simple.
In that case, the step-by-step format you've created is perfect. Sohail
Hi Adam, Am Mittwoch, 21. Mai 2014, 15:17:17 schrieb Adam Wulkiewicz:
Nice text.
Would you be so kind and see if everything is ok wth it?
Yes, but I would mark the section "Verify if your fork works*"* https://github.com/awulkiew/temp-contributing#verify-if-your-fork-works[1] as optional or "for first time users". What is missing is the rationale for always creating new branches, for features and bugs fixes. The description is ok, but the reader does not get why he should to this. And at the end you should add a short description that more commits can be added to the pull request by adding them to branch and pushing them. And I think GitHub hat some manual pages which could be linked in at several places.
In praticular I'd like to hear if this model is good for modular Boost in general?
Basically this is the way I've submitted all my pull requests. Nice work. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany -------- [1] https://github.com/awulkiew/temp-contributing#verify-if-your-fork-works
Hi, Jürgen Hunold wrote:
Hi Adam,
Am Mittwoch, 21. Mai 2014, 15:17:17 schrieb Adam Wulkiewicz:
Would you be so kind and see if everything is ok wth it? Yes, but I would mark the section "Verify if your fork works*"*
https://github.com/awulkiew/temp-contributing#verify-if-your-fork-works[1]
as optional or "for first time users".
What is missing is the rationale for always creating new branches, for features and bugs fixes. The description is ok, but the reader does not get why he should to this.
And at the end you should add a short description that more commits can be added to the pull request by adding them to branch and pushing them.
And I think GitHub hat some manual pages which could be linked in at several places.
Ok, thanks for the suggestions. I'll wait for more and make changes for a while.
In praticular I'd like to hear if this model is good for modular Boost in general? Basically this is the way I've submitted all my pull requests.
Thanks! Adam
participants (3)
-
Adam Wulkiewicz -
Jürgen Hunold -
Sohail Somani