fenics team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

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