Hi Tom: At the end of this I have a question concerning using our preferred workflow at github (assuming someone wants to take responsibility for such a move).
But first, you need some background. PLplot used CVS for a long time, then SVN for a long time, and then fairly recently made the transition to git, but with an enforced rebase workflow since that was so similar to the CVS and SVN workflow we had been using previously. And we still have core developers getting up to speed with git even though we have made it easy for them to transition from svn with the rebase workflow. We also have some developers with quite a bit more experience with git who are urging that we might want to move to a more sophisticated workflow that makes collaboration more convenient then it is with git format-patch/am, but we have proved with some git format-patch/am collaborations that that method works well, and the tradeoff for moving to a merge-based workflow appears to be either (a) a completely messed up git history that is impossible for a human to understand or (b) a complex but enforced merge-style workflow that maintains clean --first-parent history (see, e.g., <https://itk.org/Wiki/Git/Workflow/Topic#History_Shape>). In both the CMake and Itk cases, that clean --first-parent history is enforced by server side hooks, but both those related projects have a human git integration manager (Brad King in the CMake case) to help git users navigate the complex merge workflow rules (and particularly help them get the mess sorted out when they inevitably run afoul of the workflow enforcement rules). Given our own CVS/SVN background, Brad's advice when we first moved to git was to follow the enforced rebase workflow that we currently have, but he did also say after several years of that we might want to move to a git workflow similar to that used by CMake. I would not stand in the way of such a move if someone else wanted to take full responsibility for it including being the guy to interpret for the rest of our developers what has gone wrong when the server side hooks reject their pushes. Note, I am assuming here that whatever workflow we adopt will be enforced by server side hooks (just like now) because otherwise you just end up with a mess. @Tom: I assume github would allow us to set any server side hooks we wanted to use to enforce our adopted workflow (just like SF does), but could you confirm that please? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-general mailing list Plplot-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-general
