Below is another extremely useful e-mail from Brad King that I
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.
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
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
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.
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.
>>> I can explain how the history shape hooks work if needed.
>> Thanks. I would appreciate that.
>> 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
> 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
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).
Video for Nerds. Stuff that matters.
Plplot-devel mailing list