<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 22, 2013 at 3:46 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>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:<br>
<a href="http://www.mcs.anl.gov/petsc/developers/index.html" target="_blank">http://www.mcs.anl.gov/petsc/<u></u>developers/index.html</a></div></blockquote><div><br></div><div>Whoops, it seems I remembered an old discussion incorrectly. I thought someone had actually gone through with having configure write that into hgrc automatically.</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><div><br>
<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">
In such case I'm afraid I have no idea about how to ensure<br>
correct<br>
formatting other than hoping that users run pre-commit<br>
checks... :-(<br>
<br>
<br>
Education: make them fix their patches (enable those extensions,<br>
read<br>
the docs, etc) and resubmit.<br>
<br>
<br>
s/users/developers/, sorry.<br>
<br>
I'm less concerned about actual users only contributing patches, but<br>
about developers with push-permission. Every non-compliant push will<br>
make subsequent pre-commit checks fail, regardless of whether it's<br>
the particular developer's fault.<br>
<br>
<br>
The way to enforce this is to have the server reject non-conforming<br>
pushes, or to move to more of a pull model where fewer people can push<br>
directly and the trusted people can be trusted to have their local hooks<br>
configured.<br>
</blockquote>
<br></div>
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).<br>
</div></blockquote><div><br></div><div style>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</div>
<div style><br></div><div style><a href="https://bitbucket.org/site/master/issue/5658/allow-custom-pre-receive-hook-that-rejects">https://bitbucket.org/site/master/issue/5658/allow-custom-pre-receive-hook-that-rejects</a><br>
</div><div style> <br></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>
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).<br></div></blockquote><div><br></div>
<div style>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.</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>
<br>
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.</div></blockquote>
</div><br>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.</div>
</div>