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

[Barry Smith]

On Sep 3, 2014, at 8:57 AM, Jed Brown <jed at jedbrown.org> wrote:

> Patrick Sanan <patrick.sanan at gmail.com> writes:
>>> But this was my whole point in our process discussion. Tools should 
>>> subtract
>>> from what we have to worry about, not add to the cognitive load. We should
>>> all be manually checking for less, not more. A good tool would prevent any
>>> merges to master from a branch that was created from next. This seems like
>>> the simplest requirement to me.
> 
> It's not _that_ simple to define precisely in terms of the DAG.

  This hits the nail on the head!  The current git model is incomplete/problematic if it cannot handle such a simple and extremely important thing as “prevent some j-a- from f-ing up the master repository”.  

  Barry



> 
>> Should this be possible with git hooks? I've never had occasion to use 
>> them but naively, I'd want to do something like create a commit in 
>> 'next' which is tagged 'NeverMergeToMaster' 
> 
> Tags suck for this because they are not supposed to change, but 'next'
> is rewound after releases.  Better to use a special branch and compare
> against 'origin/sentinel', but is "origin" always the name of the remote
> (it's not for me)?
> 
>> and then set up a hook which will automatically reject any merge to
>> master including a commit with that tag. The practicalities aren't
>> clear to me, though, since as far as I can tell BitBucket doesn't give
>> you direct access to hooks, which you would probably need to employ a
>> strategy like this one:
>> http://stackoverflow.com/questions/13381105/git-hook-to-prevent-an-experimental-branch-pushed-to-a-release-or-master-branch
> 
> Bitbucket and GitHub do not want to be in the business of server-side
> policy because everyone wants something different and implementation is
> error-prone, so it would be an endless support issue for them.  We can
> install hooks locally (e.g., as part of configure) if necessary, just
> make sure that you run configure before merging in a repository, make
> sure that the git module is loaded when you run configure so that
> configure can run the git executable and correctly resolve the hooks
> directory, make sure that you don't use a shared clone or other sneaky
> option to have your GIT_DIR located elsewhere, don't use alternative
> porcelain for making commits, and don't use the stupid Merge button on
> the website.  Well, I guess that's a few caveats.