[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