On Thu, Sep 4, 2014 at 9:12 AM, Satish Balay <[email protected]> wrote:
> On Thu, 4 Sep 2014, Tobin Isaac 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'. > > the nightly builds are done in 'detached' mode - so this warning wil always > printed for these builds. > > And when folks hardly look at git messages - I don't thinks they will > notice > this message burried in middle of a build. [And most of the time merge/push > is done without a build]. So I don't think this change helps much.. > I will notice. Matt > Id rather folks use 'git log ..branch' before 'git merge branch' > > Satish > -- 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
