<div dir="ltr">On Tue, Jan 22, 2013 at 2:02 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@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"><div dir="ltr"><div class="gmail_extra"><div class="im">On Tue, Jan 22, 2013 at 1:28 PM, Karl Rupp <span dir="ltr"><<a href="mailto:rupp@mcs.anl.gov" target="_blank">rupp@mcs.anl.gov</a>></span> wrote:<br>
</div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Yes, I'm aware of that. Since we have to update hgrc for the BuildSystem anyway, it's 'just another line'.</div></blockquote><div><br></div></div><div>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.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
<br>
If we reject the commit server-side, the author will<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
have to edit their history (requires enabling an extension unless it's<br>
the last commit). Since it's a hassle to go back and fix the history,<br>
hopefully it will teach developers to enable the commit hooks.<br>
</blockquote>
<br></div>
Eventually we can come up with a hook that aggregates multiple commits, i.e. the user only needs to add a follow-up commit fixing the violation rather than fiddling with the history.</div></blockquote><div><br></div></div>
<div>
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.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
      -> Configure uncrustify such that it reports violations (nightly)<br>
      -> Document user-specific uncrustify configs<br>
<br>
<br>
Until someone finds a way to do this with Hg, I think this last point<br>
would only be meaningful to git users.<br>
</blockquote>
<br></div>
Albeit not ideal, I think it's reasonable to<br>
 - either wait for a similar way of doing that with Mercurial, or<br>
 - use gitifyhg<br>
for users who insist on using custom non-PETSc-style. This is a fairly low hurdle compared to what you get for it.<br></div></blockquote></div></div><br>Queue Matt screaming about how he'll never (a) use git OR (b) put a space after 'for'.</div>

</div>
</blockquote></div><br>I am not morally opposed to git (spaces after for is as attractive as crack on the repairman). However,</div><div class="gmail_extra">we will not be using git for PETSc before my daughter goes to school.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">   Matt<br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>