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

Karl Rupp rupp at mcs.anl.gov
Tue Jan 22 15:06:53 CST 2013


>      >     Yes, I'm aware of that. Since we have to update hgrc for the
>
>              BuildSystem anyway, it's 'just another line'.
>
>
>         Yeah, well, I still think it's rude for a build script to mess
>         with the
>         user's private repository configuration. We only get away with it
>         because beginners don't know better and experts usually
>         configure their
>         system so it doesn't run (e.g., by pulling BuildSystem
>         themselves) or
>         know that it's running.
>
>
>     It may be rude, but it only affects those who consider pushing to
>     petsc-dev. Among these few, how many keep a private repository
>     configuration? For all others, we ask them to send patches, so we
>     can still control the formatting issue.
>
>
> The context here was a _precommit_ hook. That runs before you've decided
> whether you're going to push anywhere. A user that is just experimenting
> with an example _should_ commit their work, but in a bookmark/branch
> that will never be pushed (though they could send a patch if they were
> asking for support). If you write a pre-commit hook into their config,
> you interfere with the functioning of their private repository. I
> consider this borderline evil.

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.

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

Best regards,
Karli




More information about the petsc-dev mailing list