fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

Is there a difference between these three?

  git-flow
  man 7 gitworkflows
  PETSc workflow

Or are they all the same thing?

--
Anders


On Thu, Apr 11, 2013 at 09:14:47AM +0800, Garth N. Wells wrote:
> The PETSc developers have laid out their approach, which includes
> fixes to releases:
>
>     https://bitbucket.org/petsc/petsc/wiki/developer-instructions-git
>
> Maybe we should follow their approach, and piggy back on their
> easy-to-follow development model documentation? Over time we can
> evolve our own workflow if required.
>
> Garth
>
> On 11 April 2013 02:32, Florian Rathgeber <florian.rathgeber@xxxxxxxxx> wrote:
> > On 10/04/13 16:29, Anders Logg wrote:
> >> On Wed, Apr 10, 2013 at 02:55:13PM +0200, Martin Sandve Alnæs wrote:
> >>> I've just pushed a critical bugfix to ufl on bitbucket, which should
> >>> be backported (cherry-picked) to 1.2. What's the procedure for this
> >>> now? Do we apply patches to the old lp series? Is there a 1.2 git
> >>> branch I can cherry-pick directly to?
> >>
> >> There's no such branch. But if we decide to follow the gitflow model,
> >> we should create a new branch called 'develop' inside the ufl
> >> repository (the branch 'master' already exists).
> >
> > Note that you can very easily resurrect any revision as any branch:
> > $ git branch <branch-name> <revision>
> >
> > But gitflow doesn't have long lived release branches:
> >
> >> All releases should be made from the 'master' branch and all
> >> development in the 'develop' branch. Before each release, one branches
> >> off 'develop' via a release branch and then into 'master'. Then after
> >> the release, the release branch gets removed.
> >>
> >> http://nvie.com/posts/a-successful-git-branching-model/
> >
> > The release branch only lives for as long as it takes to finalise the
> > release, at which point it is merged into master and that revision of
> > master is tagged with the release and the branch removed.
> >
> >> What is needed for a fix like this is to make a temporary 'hotfix'
> >> branch off 'master'. So my suggestion would be to
> >>
> >> 1. Create the 'develop' branch (from 'master')
> >>
> >> 2. Create a branch 'hotfix-1.2.1' from master
> >>
> >> 3. Fix the bug there (cherry pick from 'develop')
> >>
> >> 4. Merge the fix into 'develop' and 'master'
> >>
> >> 5. Remove the hotfix branch
> >>
> >> Steps 3-4 will be a bit different since you already made the fix in
> >> 'master'.
> >
> > I wouldn't retrospectively try to hammer history into gitflow shape.
> > Instead I would tag e21d9f6 as release 1.2.1 and start gitflow from
> > there i.e. make this also the tip of the dev branch (so this revision
> > will the the last revision ever where dev and master will point to the
> > same revision) and only work on dev from then on.
> >
> > # assuming you're on e21d9f6
> > $ git tag 1.2.1  # tag the current revision
> > $ git branch dev # create a new branch starting at the current revision
> > $ git push --tags -u origin dev
> >
> > Florian
> >
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~fenics
> > Post to     : fenics@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~fenics
> > More help   : https://help.launchpad.net/ListHelp
> >