On Fri, Aug 15, 2014 at 8:45 PM, Hazen Babcock <hbabc...@mac.com> wrote: > On 8/15/2014 2:53 PM, Alan W. Irwin wrote: >> Hi Hazen: >> >> Earlier today I sent an e-mail to Brad King, the CMake git guru (with >> CC to you to keep you fully informed) asking how they implemented the >> enforcement hooks in their git repo to maintain the desired >> --first-parent properties of the integration branches used in their >> workflow. Assuming we adopt their workflow, then I think it is >> absolutely essential that we get these enforcement hooks in place >> before proceeding further with PLplot development using git so I think >> it is a good idea to make our SF git repo read-only until this >> implementation issue for our workflow is resolved. I plan to do that >> later today if you don't have any strong objections. > > I object, but not strongly. What is the worst thing that can happen? We > have to delete the repo and start over? Hooks or no hooks, mistakes are > going to be made and will have to be dealt with, might as well start > learning how to do that now. > > In Arjen's case he would do the following: > > git checkout master > git pull > git checkout -b fix_replot_08_15_2014 > .. > edit files > .. > git add -- files > git commit -m "Fixed width issue in replot." > > .. > check that the fix works > .. > > git checkout next > git pull > git merge fix_replot_08_15_2014 > git push sf-repo next > > The only sticking point would be that we don't yet have a next (or a > release) branch in our repo.. >
I agree with Hazen here - adding hooks on day one seems overkill for the project. Further, if we do go the github route then using Github's pull request structure provides a means of enforcement and verification of whatever pre-merge checks we want to enforce. With the github fork + pull request approach a developer (any developer - core or external) would create a personal 'fork' of the main repository. A fork in this case is simply a github-generated and hosted clone of the official PLplot repository. The developer would clone their forked repository to their local machine, make and commit their changes and push the changes back to their fork on github. Once the developer is happy with their changes they can submit a pull request for their changes back to the main repository. It would then be up to one or more core developers (people with write access to the official repository) to review and accept the pull request. Once the pull request is acceppted and merged the result is a nice, clear history showing when changes were made and when they were merged. Given that the project and developers are overall new to git I think it would be premature to start stacking automated restrictions on top of our use of the tool. Hez ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
