On 2014-09-22 12:08-0400 Hazen Babcock wrote: > I think creating a branch on github (or some other public repository) is > the only way that you can proceed if you want others to see what you are > doing. Though not perhaps ideal, you should be able to rebase master off > a public branch.
Hi Hazen: Since our advice to Phil is completely contradictory, we should get this important question of workflow decided for the case of experimental topic development work (as opposed to the workflow for our more usual less controversial topic development which is normally pushed to origin master as soon as the changes by a developer pass his own tests). And once the workflow for this special case of experimental development topics is decided, we should document it in README.developers. You are much more experienced with git than me. However, I thought that rebasing a public branch was always a bad idea for the reasons I mentioned concerning disappearing commits. I am positive a number of resources I read when we were considering using a rebase workflow mentioned this drawback to that approach. Were those resources overstating the case? If they are right, then for rebase workflows like ours experimental branches should not be made accessible on public git repos since the bad choices afterwards are to rebase them periodically (which loses prior public commits) to keep up with master development or else become out of date with master. Which means some other alternative for sharing experimental development topics must be used such as sending patches to this list. My feeling is that working with such patches is unlikely to be much of a burden since git has such good facilities (format-patch and am) for generating and using such patches. Of course, if after we have gained some substantial experience with the patch method for the special case of sharing experimental development, we find that method is inhibiting our experimental development, we should move to a merge workflow instead like suggested by Brad King. But for now, let's give a good trial (at least 6 months) to our current rebase workflow including its constraint (if the resources I read are not overstating the case) that developers should refrain from sharing their experimental branches via public repos because it leads to bad further choices that typically come back to haunt you with a rebase workflow. 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 __________________________ ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
