On Wed, 3 Sep 2014, Jed Brown wrote: > Matthew Knepley <[email protected]> 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
