I have a lot of respect for Brad King (the git guru for the CMake software project, and the moving force behind CMake development). Here is part of what he had to say in response to an e-mail I sent him.
On 2014-08-18 09:20-0400 Brad King wrote: > The server side hooks of course go on the server and their impl > is not visible to clients. Our server-side hooks are not easily > re-usable because they are integrated into a bunch of ad-hoc > custom infrastructure. However, I can explain how the history > shape hooks work if needed. I replied essentially with "yes please", but we will see whether he responds further to that, and it may be moot (see rebase-only workflow comments below). Now to the interesting advice he had in general with my own remarks to you scattered throughout. > Having converted many different groups over to Git over the years > I have some advice: > > * Server-side checks form a barrier to entry for newcomers who get > frustrated trying to get past them. Often a history shape > failure requires advanced understanding to overcome. Without > such understanding the value of well-shaped history is not clear > and the developers get turned off to Git and perhaps to working > on your project. I thought <http://public.kitware.com/Wiki/Git/Workflow/Topic> was pretty clear on a good model for merge-only workflow and also felt our developers are disciplined enough to follow this workflow from the start, but Brad's experience seems to say I am wrong about that, and we should adopt a much-easier for developers rebase-only workflow instead (see below). > > * For outside contributers, encourage use of "git format-patch" > and "git am" to transfer patches by email. This avoids needing > to deal with accounts, authentication, and push instructions, > and gives you a chance to review the changes while applying them. Yep. > > * Start off with a rebase-only workflow to preserve linear history. > Use a server-side "update" hook to check that every commit in > "git rev-list $oldrev..$newrev" has only one parent. This will > give people a chance to get used to the tools without making a > mess of history. When the hook rejects someone's push, have > workflow documentation explaining how to rebase. That is a > fairly simple recovery compared to more complex history shapes. This gets back to Hazen's important question of rebase-only or merge-only. And this recommendation from Brad has a lot of impact since it is coming from the guy who put together the CMake merge-only workflow that I thought we had the developer discipline to start with. > * Later when you want to allow merges, have a single integration > manager responsible for doing them properly. Once experience is > gained then others can be trained. I am not keen on this Linus-type central dictator model. Under subversion we have trusted all our core developers not to clobber svn/trunk in the official svn repo (in git terms svn/trunk was effectively our only branch of development done with a rebase workflow). The result was svn/trunk was pretty high quality with only a few minor episodes where the result was not buildable with default CMake options. And I want to continue that model under git where our core developers (the list given at <https://www.openhub.net/p/plplot/contributors/>) all take responsibility to produce a high-quality result. I assume you do not need a central dictator to get merge-only to work. But we don't have to worry about this issue (at least to start) if we adopt a rebase-only workflow initially. > * When you eventually want to have multiple people merging regularly, > use a server-side tool to do the merges for you. We use Gerrit > Code Review for several projects other than CMake. I included this here to complete his list of recommendations, but let us ignore it for now since I suspect it is only going to be a long-term concern if/when we move from our rebase-only workflow. In sum, I think rebase-only is not only back on the table for our initial workflow model due to Brad's recommendation of it for that purpose but also likely the final choice (enforced by server-side update hook logic at push time as recommended by Brad). There are some cons to rebase-only (see <http://blogs.atlassian.com/2013/10/git-team-workflows-merge-or-rebase/> but Brad appears to be practical rather than ideological concerning the debate between rebase-only and merge-only, and obviously he does not feel rebase-only would be difficult for us to adopt for our initial git workflow. Furthermore, we have been using rebase-only workflow now for a long time (what happens with svn/trunk) so I am now strongly leaning toward rebase-only for our first git workflow with periodic review of that decision (say every year or so). I now have to read more about how rebase-only workflow works for git (especially for multiple branches which we have not used very much for subversion) to make sure I see no issues for such an initial workflow for PLplot. I am going to start with some of the links concerning rebase-only in <http://blogs.atlassian.com/2013/10/git-team-workflows-merge-or-rebase/>. Also, I would appreciate further comments from those here on this question before the final group decision is made. N.B. For those core developers here who are having trouble (because of git inexperience) following this discussion of what git workflow we should initially adopt, I highly recommend reading the first few chapters in the freely downloadable Pro Git book at <http://git-scm.com/book> for background. 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-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
