Hey, > 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).
Oh, I wasn't aware that there is some direct slamming at all. My only reference was the 'please add the line manually'-way described for petsc-dev: http://www.mcs.anl.gov/petsc/developers/index.html > 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. Do you know any clean way of rejecting non-conforming code at server-side? The obvious pre-push hook requiring developers to adjust a commit does not seem to be an option (the process of doing so might drive Barry into a berserker). The pull-model may only delegate the task of fixing a commit to the trusted developers and require additional work. so, instead of a fixing commit, we may start exchange patches (again). I'm afraid that there's not going to be a clean solution to protecting the repository. Keeping a couple of style checkers and fixing violations once in a while seems to be the most efficient approach then. Best regards, Karli
