The core PLplot developers have privately been discussing the workflow that we are going to use with our new git repo. I have moved this discussion now to plplot-devel because others there should be interested, and I may have found a solution.
I just rediscovered another important reference concerning git workflow. This one is about the workflow adopted for the CMake project itself, and I think that that workflow is what we might want to adopt ourselves. This workflow is discussed in detail with cookbooks (lists of commands to use) for all situations at <http://public.kitware.com/Wiki/Git/Workflow/Topic>. This is a pure merge workflow for a much larger project (in terms of number of developers) than PLplot. Although the resulting history is far from a linear one, it does make the history you obtain with "git log --first-parent" linear for the discussed topic, main, maint, and next branches. That attribute is enforced by an update hook at push time (which IMO is much better than one of us attempting to enforce workflow rules as some sort of repo polizei). I assume that attribute largely answers the previously expressed (in the private thread) "con" for merge workflows which is they tend to produce much too complex a history. For example, I assume it would make git-bisect much easier to use than for a more general pure merge workflow without this attribute enforced. This workflow also specifies exactly which branches to support for convenient development and is already well documented at the above URL. Furthermore, it only has one overall workflow for topic branches so you don't have to distinguish between the "unshared" and "shared" topic branches that I was privately discussing before as a possibility. WARNING. Git newbies will blanch when they first look at the above URL because there is so much detail there, but that detail is ultimately a good thing. Furthermore, they are first urged to read the initial chapters of the Pro Git book <a free download from http://git-scm.com/book> and also run git help <commandname> on the mentioned commands. But I was a complete git newbie not that long ago, but now I actually understand almost everything said at that URL. Thus, if I can understand that URL, the other newbies here should be able to do that as well if they do their git homework. :-) Also note that CMake has a very large number of developers coming from a wide variety of backgrounds (many of them git newbies to start with) and over years of lurking on the CMake devel list I have often heard questions concerning the git workflow which were normally answered by "look at the above URL". However, I haven't noticed any complaints about that workflow which says a lot about how well it works for that disparate set of developers. Anyhow, (for what it is worth because I still don't have much git experience) my vote is to use this solution for the PLplot workflow. What do the rest here (especially Hazen and Hez who are the active PLplot developers who are experienced with git) think of this possibility? 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
