On Thu, Apr 11, 2013 at 02:26:12PM -0500, Jed Brown wrote: > Andy Ray Terrel <andy.ter...@gmail.com> writes: > > > Care to comment here? > > > > > > ---------- Forwarded message ---------- > > From: Anders Logg <l...@simula.no> > > Date: Thu, Apr 11, 2013 at 1:27 PM > > Subject: Re: [Fenics] How do we do bugfix backporting now? > > To: "Garth N. Wells" <gn...@cam.ac.uk> > > Cc: FEniCSMailing List <fenics@lists.launchpad.net> > > > > > > Is there a difference between these three? > > > > git-flow > > man 7 gitworkflows > > PETSc workflow > > > > Or are they all the same thing? > > git-flow is definitely different, and I'm not a fan. I've spliced this > email with a rant I wrote to Aron, but first, let me summarize > gitworkflows(7) and PETSc's workflow, which are very close. > > gitworkflows(7) is explained in the language of a patch-based system > rather than a pull-request system. They get patch series on the mailing > lists and pipe the mailbox through 'git am' to apply patch series into > local branches (these should always start from 'master' for new > features, and 'maint' for bug fixes relevant to the last release). > Patches frequently go through several revisions before being finalized, > but in the meantime, Junio (the maintainer) puts promising-looking > series into named topic branches and merges those into a throw-away > integration branch called 'pu' (proposed updates). Patches there will > probably be reworked before they become permanent history, and 'pu' gets > rebuilt frequently (every day or two). It just provides an easy way for > people to try out "everything anyone else is working on". A throw-away > merge into 'pu' lets you find out if your work might conflict with > someone else's work without having to monitor the mailing list. You can > see all of Junio's branches here: > > https://github.com/gitster/git/branches > > Only 'maint', 'master', 'next', and 'pu' are in normal repositories. > When a topic branch is thought to be complete (perhaps after being > re-rolled or fixed up in review), it is merged to 'next' where it > undergoes testing for a while, then the topic branch is merged to > 'master' ("graduation"). If everything graduates in a release cycle, > then 'git log master..next' (shows what is in 'next', but not in > 'master') would show only merge commits from when the topics were > tested. > > I think this mailing list review and integration is among the best > possible workflows for mature projects in which all participants are > competent with their tools. But it takes a lot of discipline to > structure commits to be easily reviewable as discrete units and it > requires using email clients that "behave". In PETSc, we follow the > same principle of testing in 'next' before graduating to 'master', but > we don't have a sole "integrator". Instead, we all push our topic > branches to the same repo, which means that running 'git fetch' > automatically gets everything anyone is working on. Pushing a branch > without merging it is just offering the opportunity for passive review. > If we want review on something specific, we make a pull request. A > handful of us (mostly Barry, Matt, Satish, Karl, Peter, and I) have been > doing almost all the integration, where "integration" is defined as > merging to any of 'next', 'master', or 'maint'. > > I think this works pretty damn well, though Bitbucket doesn't have great > features for pruning stale branches. When someone clones the repo, they > get all the topic branches by default, but they are remote branches so > 'git branch' doesn't display them and 'git fetch --prune' cleans up. > But when someone forks on Bitbucket, all the branches are cloned and > there seems to be no dead-easy way to prune. This is purely an > interface tweak, but they don't have short-term plans to fix. > > > https://bitbucket.org/site/master/issue/6709/limit-which-branches-appear-in-a-fork > > Maybe if this workflow gets popularized, they'll fix the pruning issue > (which is cosmetic rather than functional anyway). It should be on GUI > widget and a handful of lines of code, but alas, their site is not open > source so we can't just add it. > > Note that you can use the same integration workflow with separate forks > instead of having all branches in one fork. Contributors that haven't > established themselves with PETSc yet are working in forks now and > sending pull requests. This is fine, but we don't see what they are > working on until they send a PR. Less work for us, but sometimes people > go down the wrong path and light review early on would help. Of course > you can always write the mailing list or even send a throw-away pull > request just asking for comments. > > > git-flow > ~~~~~~~~ > > http://nvie.com/posts/a-successful-git-branching-model/ > > I don't like git-flow because it eschews the integration process that > allows new features to interact before they are merged to 'master'. > Instead of having topic branches tested together in 'next', someone has > to be make the difficult decision of whether a topic branch that has > only been tested in isolation should be merged into 'develop' (or > hotfixes into git-flow's 'master', which is most similar to 'maint' of > gitworkflows(7)). > > This generally means that a git-flow 'develop' is less stable than a > gitworkflows(7) 'master', so it's more common to be working on a new > feature and find bugs that were there when you started. That's > disruptive to development and its unpleasant to users that would really > like the latest stuff that you think is actually ready for them to use. > > Thus any decision to merge a topic branch comes with the pressure that > any bugs introduced in the merge (possibly through indirect semantic > conflicts with other work) will disrupt any developer starting new work > between the merge and the time a fix is provided. > > Also, when nearing a release, there are more places to start development > ('master' for maintenance hot fixes, 'release-x' for bug fixes relevant > to the next release, and 'develop' for new features that will not be > merged until after the release). > > My perspective has been that 'maint'/'master'/'next', as described in > gitworkflows(7), and eliding 'pu' for most projects, is simpler, produces > cleaner history, and places less burden on the integrator to never make > mistakes. Nothing makes it to 'master' or 'maint' without first being > tested _in combination_ with other new features in 'next'. Since all > new development starts from either 'maint' (bug fixes for maintenance > releases) or 'master' (features relevant to upcoming feature release), > bugs in 'next' only affect the integration process, not the development > of new code. Starting topic branches from a stable state is important > so that you know that any new bugs are really your doing, and to prevent > needing to merge from upstream in order to fix bugs introduced prior to > starting your topic. > > I have yet to see an explanation of any benefits that git-flow provides > relative to gitworkflows(7). It is better than unstructured development > without topic branches, but I think it has only received attention > because of the nice graphic.
Thanks for this incredibly long post! I trust your judgement on this and agree that the very nice graphic for git-flow does a good job of selling it. I'll read up on gitworkflows again (only glanced through it earlier) and comment later. -- Anders _______________________________________________ Mailing list: https://launchpad.net/~fenics Post to : fenics@lists.launchpad.net Unsubscribe : https://launchpad.net/~fenics More help : https://help.launchpad.net/ListHelp
