really stop "really" commits (really!)

David Malcolm dmalcolm at redhat.com
Fri Dec 20 15:33:21 UTC 2013


On Fri, 2013-12-13 at 18:42 -0700, T.C. Hollingsworth wrote:
> Invariably when adding a patch to a spec, often I forget some detail,
> whether it be adding the %patchN macro to %prep or `git add`ing the
> patch.  It would seem I'm not alone, either.  A Google search for e.g.
> "site:https://lists.fedoraproject.org/pipermail/scm-commits/ really
> apply patch" returns tens of thousands of results!  ;-)
> 
> To prevent this from happening in the future, I wrote a little git
> pre-commit hook to help out, which I figured I'd share with you all:
> http://patches.fedorapeople.org/patchcheck.py
> 
> It verifies that:
> - all patches are committed to git
> - all patches are applied in %prep
> - no unexpanded %patch macros exist in %prep
> 
> If any of the above checks fail, the commit is aborted.

Thanks - this is a great idea.

I notice that near the top you:
  # stash any unstaged changes

and later clean it up with:
  # restore unstaged changes

There are ways of exiting the script that lead to this cleanup not
occurring - either on a specfile parse error, or if an unexpected
exception occurs - so perhaps the stash/unstash should be done using a
context manager?  (or just wrap it all in a big try/finally clause?)

Also, perhaps replace the "abort" bool with an error count, and make the
exit code be that? (and for that matter have a function to do the
sys.stderr.write/set-error dance - but now I'm bikeshedding :) )

Hope this is constructive
Dave



More information about the devel mailing list