fenics team mailing list archive

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

No need for two topic branches, it's also useful for for developers
who want to keep an eye on the latest integrated trunk (e.g. pulling
into local master daily) while working on a single local topic branch
for some time. Or maybe what I'm thinking about is more like a local
pu branch than next:

One of the points in the gitworkflows as I see it is that you try to
avoid a pattern like this:

branch master into topic
while not done:
    work on local topic
    merge official master into local topic
merge topic into master and push

because the merging of topic is then interleaved with other changes
and not easily revertable. If you instead do this:

branch master into topic
while not done:
    work on local topic
    pull official master into local master
    merge master and topic into pu for integration testing
merge topic into master and push

you get a lot of advantages like much cleaner history (the history of
topic is typically linear between the branch from master and the merge
back into master) which leads to easier debugging/blaming/reverting,
and can still test integration of others published work with your
ongoing work in the pu branch.

I actually used a similar pattern with bzr, with local branches
trunk=master, work=topicoftheday, scratch=pu, but I wasn't quite as
diciplined and probably followed the first workflow above from time to
time.

Martin

On 17 April 2013 14:18, Anders Logg <logg@xxxxxxxxx> wrote:
> So you mean it makes sense for each developer that has at least two
> topic branches?
>
> --
> Anders
>
>
> On Wed, Apr 17, 2013 at 02:15:32PM +0200, Martin Sandve Alnæs wrote:
>>    Partly true, but from a personal workflow p.o.v. it still makes sense
>>    to me:
>>
>>    - work in local mytopic
>>    - keep local master in sync by pulling
>>    - pull master into local next and merge mytopic into local next and
>>    test before merging mytopic into master and pushing
>>
>>    If you have several local topic branches you can merge them into next
>>    separately or together for testing, then later merge them one at a time
>>    into master for integration.
>>
>>    Martin
>>
>>    Den 17. apr. 2013 14:08 skrev "Anders Logg" <[1]logg@xxxxxxxxx>
>>    følgende:
>>
>>      One thing though is that it perhaps doesn't make sense to create the
>>      'next' branch at this point, until it is being tested by the
>>      buildbot?
>>      I think Johannes is working on getting it running.
>>
>> Referenser
>>
>>    1. mailto:logg@xxxxxxxxx
>>    2. mailto:meg@xxxxxxxxx
>>    3. https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
>>    4. https://bitbucket.org/petsc/petsc/wiki/developer-instructions-git
>>    5. https://bitbucket.org/petsc/petsc/wiki/quick-dev-git
>>    6. https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
>>    7. https://launchpad.net/~fenics
>>    8. mailto:fenics@xxxxxxxxxxxxxxxxxxx
>>    9. https://launchpad.net/~fenics
>>   10. https://help.launchpad.net/ListHelp
>>   11. https://launchpad.net/~fenics
>>   12. mailto:fenics@xxxxxxxxxxxxxxxxxxx
>>   13. https://launchpad.net/~fenics
>>   14. https://help.launchpad.net/ListHelp