On 2014-08-20 10:50+0100 Phil Rosenberg wrote: > Hi Alan > Just so you know, I have no real preference for either a merge or a rebase > workflow.
> I feel that merge is more idealistically "gittish" but pragmatically the rebase workflow might be easier. The downside is that branches which have been shared should not be rebased, because work that branches from it ends up containing the same commits twice (the merged version and the rebased version). I don't think that last remark can be correct if all merge commits are avoided, i.e., we use a rebase-only workflow. Up to now, PLplot developers have not shared developments of topics very much. But if they did with a rebase-only workflow, my guess is it would work exactly as in subversion; with a published topic branch for collaboration and published master (equivalent to svn trunk). To flesh out that guess, let's say someone starts a topic branch and publishes it at our SF repo. Those doing topic collaboration would first pull the published version of the topic (with --rebase option to avoid a merge and to bring all local changes of the topic branch up to speed with other's work), carry on with more development, fetch and rebase again, then finally push the topic branch to the SF repo so other collaborators could benefit from your work. From time to time one of the collaborators (assuming it is a fairly long-lived topic) would want to rebase that topic using master to keep up with master (similarly to how individuals have been using PLplot svn/trunk to develop). And ultimately when the topic matures, one of the collaborators would rebase master from the topic. and delete the topic. Note that no merge commits are done at all using this workflow. Also see discussion of rebase style workflow at <http://randyfay.com/content/rebase-workflow-git>. But I am new at this so please correct what I said, if you spot something wrong with this summary of how I think collaborative work on a topic would proceed. >I also think that the rebase method lends itself best to a single master branch rather than a trio of master, next and bug fixes. When using rebase the only way I think the three stream method would work is if we branch from master, rebase onto next or bug fixes, then at some point these get merged into master. The disadvantage is that I don't think we can differentiate mature, vs unstable topic branches in next, because after a rebase the topics don't really exist as separate entities. Pragmatically though, perhaps a single master branch would be better to start with. Walk before you run and all that. Agree with almost everything you said here. The only integration branch used for subversion has been svn/trunk, and with a rebase-only workflow, I think we could continue to be satisfied with just a master branch used the same way. That approach inspires development discipline (to keep master working at all costs), but also has the downside of inhibiting any experimental topics. But I think with rebase-only, you could also maintain a "next" branch to encourage integration testing of experimental work. And for the topics that pass all tests on next, use a rebase method to get those topics onto master. But again, please correct if I am assuming something that is not true about the rebase-only workflow. > What I do feel strongly about is the fact that whatever we do go for it will not be perfect. Things that work for other groups might not work for us, because every group and project is different. The only way we will get a system that works well for us is to use it for a while, then assess what we need to change. Don't get me wrong, making good plans and starting from a good point is essential. But when it gets to a point where you don't know the right answer it is usually because there is no right answer based on the available info so that's when it's time to start testing. Excellent points with which I agree. I take probably longer than others to get to the point of saying "Let's get on with it", but I am close to that point now. In other words, it's one of those cases where it is obviously getting very close to time to make the workflow decision even if (in worst case scenario) it is a wrong one due to lack of information. > So anyway, I think you are doing a great job of keeping this on track. As I said to start I don't have a big preference either way so if you want to take Brads advice for rebasing that works for me. OK. Thanks for the kind words. Also, since nobody else has said anything, I assume they also don't feel strongly about the workflow decision (except we should get on with it). Therefore, I have decided to follow Brad's advice and go with an initial rebase-only workflow enforced by the server-side update hook logic for that particular case. For my next step I plan to put together a rebase-only workflow document which will mostly be based on the idea to simply follow a git implementation of the rebase-only workflow that we have been using all along with subversion (except I will add a rebased next integration branch as well). I hope that document will help to give PLplot development with git a kick start! 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 __________________________ ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
