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 <gn...@cam.ac.uk> wrote: > On 24 April 2013 10:40, Martin Sandve Alnæs <marti...@simula.no> 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 >> g...@bitbucket.org: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 <gn...@cam.ac.uk> wrote: >>> On 23 April 2013 22:10, Johan Hake <hake....@gmail.com> 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) >>>>> >>>>> -- >>>>> 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 >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~fenics >>>> Post to : fenics@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~fenics >>>> More help : https://help.launchpad.net/ListHelp >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~fenics >>> Post to : fenics@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~fenics >>> More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~fenics Post to : fenics@lists.launchpad.net Unsubscribe : https://launchpad.net/~fenics More help : https://help.launchpad.net/ListHelp
