Hi David: I changed the subject line to something more appropriate.
On 2014-09-23 09:54-0700 David MacMahon wrote: > Hi, Alan, > > On Sep 22, 2014, at 12:37 PM, Alan W. Irwin wrote: > >> 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. > > I agree that rebasing any part of a branch that has been pushed is a bad idea. It makes things complicated/inconvenient for those who are following the branch. > >> 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. > > I can understand the desire for a nice clean linear history, especially since the code was just migrated from Subversion. Strict adherence to a rebase only workflow will definitely result in a nice clean linear history. Starting with a strict "rebase only workflow" requirement, the statement quoted above sounds reasonable, but the "experimental branches should not be made accessible on public git repos" part of it really sounds wrong to me. It makes me wonder whether a strict rebase only workflow is really best. > >> 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. > > Emailing patches is tedious and error prone. Yes, git has good facilities for this, but it has even better facilities for sharing changes: pushing to public repos. Asking developers to refrain from pushing their experimental branches to public repos is somewhat hobbling, IMHO. I disagree. I have been applying user-generated patches to PLplot for years without any patch-related errors. And I really like the git format-patch command to generate a patch (which I have used to submit fixes to the cmake developer's list just like many others do there because that is the patch format particularly encouraged by Brad King for use by external developers). And I have had no problem already applying (using git am) an external patch for PLplot a git format-patch to PLplot supplied by an external developer. And sharing work using patches generated by git format-patch has not been an issue for years on the cmake-devel mailing list, the wine-devel list, and for the X intel graphics list and the cairo list when I was monitoring those. > >> 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. > > I am not familiar with Brad King's merge workflow, but I think allowing some merge commits can be a good thing. A compromise between a rebase-only workflow and an unconstrained merge workflow would be to allow merge commits on master but only if the first parent of such merge commits is also on the master branch. That is exactly the "first-parent" merge workflow that is advocated by Brad King for experienced git users. (See <http://public.kitware.com/Wiki/Git/Workflow/Topic> for a full description.) > Developers would still be allowed (encouraged?) to follow a rebase-as-much-as-possible workflow, but they could also push their experimental branches to public repos without having to worry about rebasing them later. This would allow for a concise summary of changes on master by running "git log --oneline --first-parent master". Each non-merge commit on master would be shown along with the merge commit from each (non-rebased) topic branch, but the topic branch commits themselves would not be shown (because we passed "--first-parent"). > Personally, I find merge commits to be a helpful way of partitioning the history of a project, especially when using gitk or "git log --graph". They are kind of analogous to subdirectories in that not having merge commits is kind of like keeping all your files in one directory. When running "git log --graph", merge commits make it easy to see which commits "go together" because they are shown on the same topic/experimental branch. Without merge commits, everything is just one lone thread of development. Of course it is possible to overuse merge commits, but generally if a topic branch is significant enough to share before rebasing it to master, then it's probably significant enough to warrant a merge commit on master when the time comes to bring the topic branch back into the fold. You have made a number of points which I agree with (except for your comment about using patches). It is clear our adopted (enforced) git rebase workflow is only a baby step away from the subversion workflow which doesn't offer any alternative other than rebase. And such a baby step has the downside that extreme care should be used with publishing topic branches. (See the new wording in README.developers which expresses a consensus arrived at between Hazen and me concerning this issue.) But Brad King (who has advised many groups migrating from subversion over the years) strongly advised we take this baby step first to gain essential experience with git as a group, before moving to the (enforced) git merge workflow described above. > Hope this helps Yes it does because workflow choice is an extremely important topic to discuss for any group developing software using git. I think we are mostly in agreement here. Remember that most of our active developers (including me) were not familiar at all with using git for development. Therefore, the current rebase workflow advocated by Brad King for git beginners is right for us for now despite its drawback that caution must be used for published topic branches. But when in 6 months to a year or so from now we are ready to move from this current adopted rebase workflow to the merge workflow described above, I agree we will realize some additional benefits from git (i.e., less error-prone sharing of topics). However, note that we will need that substantial git group experience to use that merge workflow because of its downside. Which is that when pushes to the server are rejected because they do not maintain first-parent clarity, it is much harder to figure out the mess (according to Brad King) than for our current enforcement rule which simply rejects all merges that are not fast-forward. Also note that there is no simple way to enforce the first-parent workflow on the client side. In contrast, that can easily be done for the current rebase workflow (see our README.developers file for details) so that our developers have the opportunity to catch rebase workflow errors right away rather than having to wait to see whether the server rejects their push. 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
