fenics team mailing list archive

[Jed Brown <jed@xxxxxxxx>]

Anders Logg <logg@xxxxxxxxx> writes:
> I read up on the PETSc workflow and gitworkflows and think it looks
> very good. I'll propose that we adopt the gitworkflows model (without
> the 'pu' branch, at least initially).
>
> One thing that I found confusing at first is that I felt the model
> would lead to 'next' degrading over time - topic branches get merged
> in for testing and those that don't make it to 'master' get stuck in
> there forever. But this seems to be taken care of by the "rewind and
> rebuild" of 'next' after release.

Yes, also note that if a topic merged to 'next' is abandoned (e.g., you
decide it's not a good approach to the problem), you would revert it on
'next'.  If it's just not mature yet, it rides along in 'next' until a
release and then becomes part of the rewound 'next'.

At any point

  $ git log --no-merges master..next

shows all the commits that have not yet graduated.  If you use topic
branches on the server like PETSc or https://github.com/gitster/git,
then

  $ comm -12 <(git branch -r --no-merged master | sort) <(git branch -r --merged next | sort)

shows the name of all the topic branches that have not graduated.  I use
a combination of this and the decorated log command below to check for
stragglers.

  $ git log --graph --decorate --oneline --topo-order --no-merges master..next