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

[Barry Smith]

On Sep 4, 2014, at 6:03 AM, Matthew Knepley <knepley at gmail.com> wrote:

> On Thu, Sep 4, 2014 at 12:56 AM, Tobin Isaac <tisaac at ices.utexas.edu> wrote:
> 
> My personal opinion is that maintaining a catalog of undesirable commits
> and detection/enforcement logic is not the best use of maintainer time
> and will not result in a more efficient system.  But if you want to
> spend your time on it, give it a shot and maybe others will use it too.
> 
> Funny you should say that.
> 
> https://bitbucket.org/petsc/petsc/commits/a04f2a265ee1457256d59a436256ddce6a927374
> https://bitbucket.org/petsc/petsc/commits/7a9516f4bcf47790ec9d70380d83bb015f0d3e8e
> 
> My idea here is (a) create a dotfile in a commit that only gets merged
> into next, and (b) add a hook to 'make info' that warns you if that
> file is present and your branch isn't named 'next'.  This change
> doesn't help a maintainer, who knows the workflow and can spot
> undesirable commits better than a script, but it does reach out to
> developers who, ehm, may not have read the wiki, and warns them as
> soon as they start to test their changes on a branch that was based on
> 'next'.
> 
> Cool, that is what I want.

   What I want is a pure git solution based on git providing a “universal client hook” for all its commands allowing a repository to interpose any programatic rules they want. But instead git provides a handful of odd-ball client hooks because they are the only thing Linus personally gives a shit about! It is like git goes out of its way to make it difficult or next to impossible to provide programatic rules.

  Barry

> 
>   Matt
>  
>   Toby
> 
> -- 
> 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