[petsc-dev] Style Guide: How to format single-line if/for/while-blocks?

[Karl Rupp]

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