On Sep 4, 2014, at 6:03 AM, Matthew Knepley <[email protected]> wrote:
> On Thu, Sep 4, 2014 at 12:56 AM, Tobin Isaac <[email protected]> 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
