Re: [Plplot-devel] Trying to understand how git workflow for CMakeis enforced
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 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. 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. 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. Phil -Original Message- From: Alan W. Irwin ir...@beluga.phys.uvic.ca Sent: 20/08/2014 01:31 To: PLplot development list Plplot-devel@lists.sourceforge.net Subject: Re: [Plplot-devel] Trying to understand how git workflow for CMakeis enforced Below is another extremely useful e-mail from Brad King that I would like to preserve on the plplot-devel list because it includes the detailed update hook logic needed for enforcement of a good history shape for a merge workflow and other useful comments. If we decide to start with a merge workflow, we can use this logic immediately. If we decide instead to follow Brad's suggestion of starting with a rebase workflow and moving to a merge workflow later, then this logic will be useful on that later occasion. Note, buried in Brad's e-mail from yesterday was a comment on the alternative update hook enforcement logic for the rebase workflow which I repeat here to make sure the two alternative sets of update hook logic appear in the same e-mail. [For the rebase approach u]se a server-side update hook to check that every commit in git rev-list $oldrev..$newrev has only one parent. That is not as detailed as what he said below, but I think it should be completely straightforward to figure out a bash loop to stick in the update hook to check a list of commits created as above to make sure if developers have used merges they have been of the fast-forward variety. So Brad has effectively supplied the update hook enforcement logic we need for each of the two general rebase or merge workflow alternatives. The next thing we have to do is to decide whether we adopt rebase workflow now and move to merge workflow later (as suggested by Brad to all groups of developers he has advised who are starting out with git) or jump into merge workflow immediately. As I said earlier today, I am leaning pretty hard towards Brad's suggestion, but I would appreciate your comments on this issue, and I also need some time to read more about rebase workflow before we come to a final decision. With your help, I hope that decision is by late this week so we can start developing PLplot using git without too much further delay. To summarize what has been going on so far in these discussions, I discovered very soon in my wholesale introduction to git that merges are an incredibly powerful weapon in the git arsenal. And I think everyone who has more experience with git or done their initial reading about it will confirm that assessment. So developers for a given project like PLplot (or timeephem) should have a firm workflow policy decided in advance about how to constrain the use of that merge weapon. Thanks to quite useful recent input from Brad King, I think we are getting much closer to a decision about what initial workflow to adopt for PLplot. Alan On 2014-08-19 15:41-0400 Brad King wrote: On 08/18/2014 02:06 PM, Alan W. Irwin wrote: The current set of active core PLplot developers is a small but quite disciplined group, and there has been quite a lot of interest in keeping a clean history shape in discussions of our git workflow. Okay. I can explain how the history shape hooks work
Re: [Plplot-devel] Trying to understand how git workflow for CMakeis enforced
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
Re: [Plplot-devel] Trying to understand how git workflow for CMakeis enforced
Hi Alan Re rebase, and shared topic branches see the second half of http://git-scm.com/book/en/Git-Branching-Rebasing. I still don't fully understand the implications, but it seems that if you branch from a branch that gets rebased, then you can/will end up with the same changes being included twice. I'm not sure what the implications are, whether it just makes for odd and untidy history or if it actually causes conflicts like trying to apply the same patch twice. Also don't forget that other people on the www might find and fix bugs in our code so we must rely on them being able to generate patches - although I haven't read anything about how patches work in git. If they happen to have branched from an experimental branch, because it included a feature they liked then we could have problems. Easiest way to avoid it presumably is to keep branches private. This might seem restrictive for now, but maybe we should see how it goes for a while and if it is too restrictive then we consider putting the extra work into a merge workflow. Phil From: Alan W. Irwin ir...@beluga.phys.uvic.ca To: Phil Rosenberg philip_rosenb...@yahoo.com Cc: PLplot development list Plplot-devel@lists.sourceforge.net Sent: Wednesday, 20 August 2014, 12:35 Subject: RE: [Plplot-devel] Trying to understand how git workflow for CMakeis enforced 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
Re: [Plplot-devel] Trying to understand how git workflow for CMakeis enforced
On 2014-08-20 09:07-0700 phil rosenberg wrote: Hi Alan Re rebase, and shared topic branches see the second half of http://git-scm.com/book/en/Git-Branching-Rebasing. I still don't fully understand the implications, but it seems that if you branch from a branch that gets rebased, then you can/will end up with the same changes being included twice. I'm not sure what the implications are, whether it just makes for odd and untidy history or if it actually causes conflicts like trying to apply the same patch twice. Thanks for that heads up. I have done some additional research this morning and all sources are consistent about this warning concerning rebase workflow. So I believe it, and my remarks about collaborating with published topic branches with a rebase workflow should be ignored. [... This rebase workflow] might seem restrictive for now, but maybe we should see how it goes for a while and if it is too restrictive then we consider putting the extra work into a merge workflow. Agreed. @Everybody: Instead of writing a rebase workflow document myself that we could use, I have been looking for something like that written by someone else. What do you think of adopting (the quite restrictive) rebase workflow outlined in http://kevinold.com/2013/04/17/my-git-workflow.html to start? No integration branches other than master. No published topic branches. But dead simple and very much like our previous svn-based 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 __ -- 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
