On Mon, Apr 15, 2013 at 08:46:44AM -0500, Jed Brown wrote: > Anders Logg <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~fenics Post to : [email protected] Unsubscribe : https://launchpad.net/~fenics More help : https://help.launchpad.net/ListHelp
