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.. Id rather folks use 'git log ..branch' before 'git merge branch' Satish
