On 01/20/2011 04:34 AM, Jim Meyering wrote: > This is in preparation for hooking this rule to "check" > at least in coreutils. Today I was burned once again by > pushing a non-public submodule reference (coreutils). > The fact that this check is currently run only at release time > is good, but obviously not enough. > > It probably belongs on a server-side commit hook, too. > > As a possible follow-on idea, ... > So far, I don't see a down-side to adding this line to maint.mk: > > check: public-submodule-commit
The rule is a no-op for projects that use gnulib and maintainer-makefile but do not use git submodules (or even git at all), so I'm okay with it on that front. However, there are times when I specifically commit a private gnulib commit to my private clone of a repository, since that makes it easier to pull from my private clone on multiple machines to test whether a potential gnulib patch has merit. I guess it would be easy enough to use 'make -k check' in those cases, although it becomes a bit more effort to inspect the logs in those cases to ensure the only failure was indeed from the known-private submodule and not from a regression introduced by using the candidate gnulib commit. I'm 60:40 in favor of including the 'check: public-submodule-commit' hook at the moment. -- Eric Blake [email protected] +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
