fenics team mailing list archive
-
fenics team
-
Mailing list archive
-
Message #02114
Re: Fwd: How do we do bugfix backporting now?
On Mon, Apr 15, 2013 at 08:46:44AM -0500, Jed Brown wrote:
> 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
Thanks! I'll store those in my sack of git charms.
--
Anders
References