On Tue, Jan 22, 2013 at 3:06 PM, Karl Rupp <rupp at mcs.anl.gov> wrote:
> A user that is just experimenting with an example will not set up the > pre-commit hook anyway. I still rely on developers adding the pre-commit > hook by themselves rather than magically interfering with hgrc. The latter > would be borderline evil, yes. > Okay, note the original context: >> Note that pre-commit cannot be run on a user's machine without their >> assistance (configuring hgrc). (Doing so would be a huge security >> vulnerability.) > Yes, I'm aware of that. Since we have to update hgrc for the BuildSystem anyway, it's 'just another line'. which is why I thought you were going to have configure slam some commit hook crap into the user's hgrc (like it sometimes does for BuildSystem because we haven't switched to using submodules). > > > This is horrible because the aggregating commit will touch lots of >> irrelevant lines. If it does more than change whitespace, git/hg >> can't >> even give us a diff that looks past that rearrangement. It's >> important >> for every commit making it into the repository to be formatted >> consistently. >> >> >> In such case I'm afraid I have no idea about how to ensure correct >> formatting other than hoping that users run pre-commit checks... :-( >> >> >> Education: make them fix their patches (enable those extensions, read >> the docs, etc) and resubmit. >> > > s/users/developers/, sorry. > > I'm less concerned about actual users only contributing patches, but about > developers with push-permission. Every non-compliant push will make > subsequent pre-commit checks fail, regardless of whether it's the > particular developer's fault. > The way to enforce this is to have the server reject non-conforming pushes, or to move to more of a pull model where fewer people can push directly and the trusted people can be trusted to have their local hooks configured. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130122/6129d0e6/attachment.html>
