fenics team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

Partly true, but from a personal workflow p.o.v. it still makes sense to me:

- work in local mytopic
- keep local master in sync by pulling
- pull master into local next and merge mytopic into local next and test
before merging mytopic into master and pushing

If you have several local topic branches you can merge them into next
separately or together for testing, then later merge them one at a time
into master for integration.

Martin
Den 17. apr. 2013 14:08 skrev "Anders Logg" <logg@xxxxxxxxx> følgende:

> One thing though is that it perhaps doesn't make sense to create the
> 'next' branch at this point, until it is being tested by the buildbot?
>
> I think Johannes is working on getting it running.
>
> --
> Anders
>
>
> On Wed, Apr 17, 2013 at 12:48:30PM +0100, Garth N. Wells wrote:
> > So in summary, do we agree as a start to adopt the 'gitworkflows' work
> > flow minus 'pu', and to use the PETSc detailed git instructions for
> > beginners on how to implement gitworkflows (i.e. use the PETSc docs to
> > know what command to type . . . ).
> >
> > Garth
> >
> > On 15 April 2013 14:10, Marie E. Rognes <meg@xxxxxxxxx> wrote:
> > > On 04/15/2013 03:08 PM, Anders Logg wrote:
> > >>
> > >> On Mon, Apr 15, 2013 at 03:01:23PM +0200, Marie E. Rognes wrote:
> > >>>
> > >>> On 04/15/2013 02:47 PM, Anders Logg wrote:
> > >>>>
> > >>>> On Mon, Apr 15, 2013 at 02:43:14PM +0200, Marie E. Rognes wrote:
> > >>>>>
> > >>>>> On 04/15/2013 02:37 PM, Anders Logg wrote:
> > >>>>>>
> > >>>>>> I suggest we adopt the "gitworkflows" development model as
> described
> > >>>>>> here:
> > >>>>>>
> > >>>>>>
> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
> > >>>>>>
> > >>>>>> (Can also be read by the command 'man 7 gitworkflows'.)
> > >>>>>>
> > >>>>>> In more detail, I suggest we
> > >>>>>>
> > >>>>>> - create 'maint', 'master', 'next' branches in the official
> repository
> > >>>>>>
> > >>>>>> - skip the 'pu' branch for now
> > >>>>>>
> > >>>>>> - publish topic branches in personal repositories
> > >>>>>>
> > >>>>>> - follow the "gitworkflows" model otherwise
> > >>>>>>
> > >>>>>> Core developers should read up on the description of gitworkflows
> and
> > >>>>>> comment. Any objections to adopting this model?
> > >>>>>>
> > >>>>>> The main motivation is that this is a standard model used by many
> > >>>>>> other projects, including our PETSc friends who can share their
> > >>>>>> experience and give us pointers when we stumble.
> > >>>>>
> > >>>>> So, you are referring to the PETSc model as described here:
> > >>>>>
> > >>>>>
> https://bitbucket.org/petsc/petsc/wiki/developer-instructions-git
> > >>>>>    https://bitbucket.org/petsc/petsc/wiki/quick-dev-git
> > >>>>>
> > >>>>> as suggested earlier by Garth? Sounds good to me.
> > >>>>
> > >>>> No, I'm referring to
> > >>>>
> > >>>>
> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
> > >>>>
> > >>>> minus the 'pu' branch.
> > >>>
> > >>> Are there any crucial differences? As far as I can see, the PETSc
> > >>> wiki provides a bit more detail (very useful for those of us new to
> > >>> git) and specific naming suggestions.
> > >>
> > >> Yes it's useful so it is definitely worth reading. It's also very
> > >> close to gitworkflows. But if we should adopt a model, I prefer to say
> > >> that we adopt the "gitworkflows model", instead of "the gitworkflows
> > >> model as currently interpreted by the PETSc developers".
> > >
> > >
> > > Ok, thanks for clarifying. Still sounds good to me.
> > >
> > >
> > >
> > > _______________________________________________
> > > Mailing list: https://launchpad.net/~fenics
> > > Post to     : fenics@xxxxxxxxxxxxxxxxxxx
> > > Unsubscribe : https://launchpad.net/~fenics
> > > More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~fenics
> Post to     : fenics@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fenics
> More help   : https://help.launchpad.net/ListHelp
>