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
