On Wed, Sep 3, 2014 at 2:30 PM, Jed Brown <[email protected]> wrote: > Matthew Knepley <[email protected]> writes: > > The concrete proposal has been made many times. Here it is again: Do not > > let anyone merge next into master. > > Which 'next'? What about parents of 'next' or abandoned branches? Do > we care about the local 'next' or the 'next' associated with a remote? > Which remote? Recall that in this case, it wasn't "git merge next", but > someone starting a branch in a different repository that contains > commits not present in 'master'. Define what you mean there. What if > someone starts that branch and rebases onto 'master' (rewriting commits > From 'next' so that they are not longer in the history of 'next')? > > But "don't merge 'next' into 'master'" is laughably short of the scope > of what you are really asking for. If you want to make a serious > proposal, do that.
Pretending not to see a problem will not make it magically go away. > > Babbling about how easy errors are to avoid is senseless, and > > completely blind to all the neurological research. People make simple > > mistakes all the time in every endeavor. > > Add "review the commits in branch" to your merge checklist. > Of course, and a manual checklist is obviously better than automating the check. Lets get rid of all pointer checks in PETSc. The users obviously know that they should never pass a NULL pointer. Just look at the documentation. And type checking is just senseless because the user ought to have passed the right type in, and they can figure it out if something goes wrong. We spend entirely too much time on things that users should be doing themselves. Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener
