fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

Sounds like a good suggestion. The naming convention fix-issue-N means
it won't really clutter the list of branches.

But how does this fit into the gitworkflows model? They only seemt to
mention hotfix branches for fixing stuff in released versions.

--
Anders


On Wed, Apr 24, 2013 at 03:53:27PM +0200, Martin Sandve Alnæs wrote:
> We could say we remove all fix-issue-N branches e.g.  after each
> release. That's just a bash for loop. For removal of stale branches in
> general, we can just encourage everyone to take a look after each
> release.
>
> On 24 April 2013 15:47, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
> > On 24 April 2013 10:40, Martin Sandve Alnæs <martinal@xxxxxxxxx> wrote:
> >> I also think that for small safe fixes that have passed the tests,
> >> merging into master and skipping next is fine. It is crucial though
> >> that the tests have passed before pushing the merge, otherwise
> >> we won't be able to keep master green.
> >>
> >> But shouldn't the fix branch be kept for a while and not deleted right away?
> >>
> >> E.g. if the next branch is reset and topic branches are merged into
> >> next again, the fix might be needed?
> >>
> >> E.g. if I have a topic branch in progress that will take a while, I may
> >> need to merge just the fix into my topic branch without getting all of
> >> master, but might not see that at the moment the fix is merged into master.
> >>
> >> There might be an awful lot of fix branches though...
> >
> > I don't have enough git experience to say whether quick removal is a
> > problem. I have plenty of experience that if something is not removed
> > quickly it will stay around for a long time :).
> >
> > Garth
> >
> >> Maybe if we have a convention for the naming of issue branches,
> >> e.g. fix-issue-#, then the branch list will be more readable even if long.
> >> That has the advantage of making an easy connection to issue and fix.
> >>
> >> Also note that you won't see the remote branches by default, so a long
> >> remote branch list only clutters the display of all remote branches,
> >> not the 'git branch' display:
> >>
> >> martinal@martinal-mac:~/dev/fenics/temp$ git clone
> >> git@xxxxxxxxxxxxx:fenics-project/ufc.git
> >> Cloning into 'ufc'...
> >> remote: Counting objects: 3228, done.
> >> remote: Compressing objects: 100% (1171/1171), done.
> >> remote: Total 3228 (delta 1754), reused 3197 (delta 1738)
> >> Receiving objects: 100% (3228/3228), 452.16 KiB | 298 KiB/s, done.
> >> Resolving deltas: 100% (1754/1754), done.
> >> martinal@martinal-mac:~/dev/fenics/temp$ cd ufc/
> >> martinal@martinal-mac:~/dev/fenics/temp/ufc$ git branch
> >> * master
> >> martinal@martinal-mac:~/dev/fenics/temp/ufc$ git branch -a
> >> * master
> >>   remotes/origin/HEAD -> origin/master
> >>   remotes/origin/maint
> >>   remotes/origin/master
> >>   remotes/origin/next
> >> martinal@martinal-mac:~/dev/fenics/temp/ufc$ git checkout -b maint origin/maint
> >> Branch maint set up to track remote branch maint from origin.
> >> Switched to a new branch 'maint'
> >> martinal@martinal-mac:~/dev/fenics/temp/ufc$ git branch
> >> * maint
> >>   master
> >>
> >>
> >> Martin
> >>
> >>
> >> On 24 April 2013 11:17, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
> >>> On 23 April 2013 22:10, Johan Hake <hake.dev@xxxxxxxxx> wrote:
> >>>> How do we think about small 1 commit fixes? Should these first be pushed
> >>>> to next?
> >>>
> >>> I think 'next' might be overkill for this. What about a 'fix' branch,
> >>> merge into master and delete the 'fix' branch?
> >>>
> >>>> Do we have a buildbot testing the next branch?
> >>>>
> >>>
> >>> If we have the resources, it would be good to test both master and
> >>> next, with the intention that master is almost always green, and next
> >>> we try to keep green but not minding if it sometimes fails.
> >>>
> >>> Garth
> >>>
> >>>> Johan
> >>>>
> >>>> On 04/23/2013 10:06 PM, Anders Logg wrote:
> >>>>> Dear all,
> >>>>>
> >>>>> A couple of developers told me last week they were waiting for the
> >>>>> dust to settle before jumping in and working actively with the new
> >>>>> code repositories. I think the dust has now settled (with yet another
> >>>>> rewrite of the FFC repository yesterday) and it's safe to jump in.
> >>>>>
> >>>>> As before, please read up on
> >>>>>
> >>>>>    http://git-scm.com/book
> >>>>>    https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
> >>>>>    https://bitbucket.org/petsc/petsc/wiki/developer-instructions-git
> >>>>>
> >>>>> One thing I would suggest now is that core developers publish branches
> >>>>> they intend to merge as part of the main repositories (as opposed to
> >>>>> storing them in personal repositories). It makes it easier for others
> >>>>> to follow the development. Note e.g. that PETSc has 66 branches at the
> >>>>> moment. Examples would be the UFL repository which could have the
> >>>>> following branches:
> >>>>>
> >>>>>   master
> >>>>>   next
> >>>>>   martinal/subdomains
> >>>>>   martinal/signatureopt
> >>>>>   logg/tuplenotation ;-)
> >>>>>
> >>>>> Issues we still need to discuss (please jump in) are:
> >>>>>
> >>>>> - Moving questions to stackexchange (comment on previously suggested
> >>>>>   instructions)
> >>>>>
> >>>>> - Updating the information on the web pages (please help out)
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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
> >>>
> >>> _______________________________________________
> >>> 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