[petsc-dev] 'master' RESET after bad merge! - 'tisaac/thplex' was based on 'next'

[Satish Balay]

On Wed, 3 Sep 2014, Jed Brown wrote:

> Matthew Knepley <knepley at gmail.com> writes:
> > This is truly a low point for your argument. You are not arguing against the
> > usefulness, nor that automation is better than doing it by hand, but that it
> > did not happen for a while and moral use of VC dictates that you do it
> > manually?
> > That is crazy.
> 
> A human has to review branches before merging.  Full stop.  There is no
> other option until computers become so advanced that they put
> programmers out of business.
> 
> When you review a branch, you see what commits are coming in.  If you
> don't review the branch, there are countless ways to merge things that
> you don't want.  The specific accident of merging 'next' into 'master'
> or 'maint' is not the worst and actually fairly easy to notice.
> 
> And now we're back to my request: if you want the system to enforce
> policy, make a concrete proposal for the precise semantics.  Otherwise
> take heart that the mistake we're babbling on about cannot occur if we
> do our jobs of reviewing branches before merging them.

Wrt next branch - one thing we can do:

Have a tag say in petscversion.h or petscbranch.h
#define PETSC_BRANCH next

And now the trigger script can always check this file - and prevent a
'push' to any branch other than next. [I'm assuming the trigger script
is on the server side - so it won't prevent a merge to maint/master -
but a push to maint/master]

I'm not sure how to do this for maint/master [prevent branches off
master from merging into maint - except at release time]

And locally want you want is for all 'integrators' is:

ailas 'git merge branch' = 'git log --oneline ..branch && pause && git merge branch'

Obviously git prints lots of info - and if we don't read that [and
incorrectly assume the 'git state' we are in] - we can mess up things.

Satish