<div dir="ltr">On Tue, Jan 22, 2013 at 2:42 PM, Karl Rupp <span dir="ltr"><<a href="mailto:rupp@mcs.anl.gov" target="_blank">rupp@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<div class="im"><br>
<br>
>     Yes, I'm aware of that. Since we have to update hgrc for the<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    BuildSystem anyway, it's 'just another line'.<br>
<br>
<br>
Yeah, well, I still think it's rude for a build script to mess with the<br>
user's private repository configuration. We only get away with it<br>
because beginners don't know better and experts usually configure their<br>
system so it doesn't run (e.g., by pulling BuildSystem themselves) or<br>
know that it's running.<br>
</blockquote>
<br></div>
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.</blockquote>
<div><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
    Eventually we can come up with a hook that aggregates multiple<br>
    commits, i.e. the user only needs to add a follow-up commit fixing<br>
    the violation rather than fiddling with the history.<br>
<br>
<br>
This is horrible because the aggregating commit will touch lots of<br>
irrelevant lines. If it does more than change whitespace, git/hg can't<br>
even give us a diff that looks past that rearrangement. It's important<br>
for every commit making it into the repository to be formatted consistently.<br>
</blockquote>
<br></div>
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... :-(<br></blockquote><div><br></div><div style>Education: make them fix their patches (enable those extensions, read the docs, etc) and resubmit.</div>
</div></div></div>