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
