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

[Jed Brown]

On Tue, Jan 22, 2013 at 3:46 PM, Karl Rupp <rupp at mcs.anl.gov> wrote:

> 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<http://www.mcs.anl.gov/petsc/developers/index.html>
>

Whoops, it seems I remembered an old discussion incorrectly. I thought
someone had actually gone through with having configure write that into
hgrc automatically.


>
>
>
>               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).
>

Anything run client side can be cheated (and isn't even enabled by default)
so you put the hook on the server. Naturally, hosting sites tend not to
like running arbitrary user code

https://bitbucket.org/site/master/issue/5658/allow-custom-pre-receive-hook-that-rejects


> 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).
>

Well, one option with the pull model would be to have a bot that inspects
pull requests and replies to the submitter with the list of violations and
instructions for running the hook locally.


>
> 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.
>

One important principle is that the person submitting code has to be
responsible for fixing (perhaps "automatically") their formatting. It's not
remotely acceptable to have a weekly script that "fixes" everything.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130122/d9b779b1/attachment.html>