<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 22, 2013 at 3:06 PM, Karl Rupp <span dir="ltr"><<a href="mailto:rupp@mcs.anl.gov" target="_blank">rupp@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":5y7">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.</div>
</blockquote><div><br></div><div style>Okay, note the original context:</div><div style><br></div><div style><div>>> Note that pre-commit cannot be run on a user's machine without their</div><div>>> assistance (configuring hgrc). (Doing so would be a huge security</div>
<div>>> vulnerability.)</div><div><br></div><div>> Yes, I'm aware of that. Since we have to update hgrc for the BuildSystem anyway, it's 'just another line'.</div><div><br></div><div style>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).</div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":5y7"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
        This is horrible because the aggregating commit will touch lots of<br>
        irrelevant lines. If it does more than change whitespace, git/hg<br>
        can't<br>
        even give us a diff that looks past that rearrangement. It's<br>
        important<br>
        for every commit making it into the repository to be formatted<br>
        consistently.<br>
<br>
<br>
    In such case I'm afraid I have no idea about how to ensure correct<br>
    formatting other than hoping that users run pre-commit checks... :-(<br>
<br>
<br>
Education: make them fix their patches (enable those extensions, read<br>
the docs, etc) and resubmit.<br>
</blockquote>
<br></div>
s/users/developers/, sorry.<br>
<br>
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.<br>
</div></blockquote></div><br>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.</div>
</div>