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 if needed. >> >> Thanks. I would appreciate that. > [snip] >> I have already looked at the possibility of complementing the update >> hook rule referred to above with the (voluntary) client-side rules "no >> merges from next to any branch" and "no merges from master except to >> next" to implicitly preserve good shape of history. But I am pretty >> sure the problem with that approach is identifying the parents and >> associated branches of the merge commit that is about to take place >> using a client-side hook. Is that what you are implying by the remark >> above? If identifying the parents is impossible from the client-side, >> I will give up on that approach and stick with an update push rule >> alone. > > It is not possible to check this from the client side because it is > always possible that someone else will win the race to push. The > history shape enforcement depend on checking the way a branch head > moves forward on each push, so it must be server-side. > > The server-side history shape checks are implemented in the 'update' > hook, which gets 'refname', 'oldrev', and 'newrev' arguments. I'll > assume they have been parsed into such-named shell variables. The > checks are implemented as follows in pseudo-shell code: > > * fast-forward update > Check that the oldrev is reachable from the newrev: > > base=$(git merge-base $oldrev $newrev) > test $base = $oldrev > > * first-parent sequence preserved > Check that the oldrev is reachable in a first-parent walk from > the newrev: > > first=$(git rev-list --reverse --first-parent $oldrev..$newrev | head -n 1) > base=$(git rev-parse $first^1) > test $base = $oldrev > > * 'next' not reachable from other branches > The first (merge) commit in 'next' should never be reachable from > other branches. If $refname is not 'next' then check that the > commit is not reachable from $newrev: > > if test "$refname" != "refs/heads/next"; then > base=$(git merge-base $newrev $first_commit_in_next) > test "$base" != $first_commit_in_next > fi > > -Brad > __________________________ 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
