fenics team mailing list archive

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

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)
>>>>>
>>>>> --
>>>>> Anders
>>>>>
>>>>> _______________________________________________
>>>>> 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