<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 3, 2013 at 11:23 AM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>How do you identify what the feature is when it's in 10 commits interspersed over 200 in the history. My claim is that you should make those 10 commits on top of each other without merging (unless you need sometIhing specific that was pushed to petsc-dev) and merge when it's complete. Pushing to petsc-dev should _mean_ that it's ready for review. This does not take more work.</div>


</div></div></div>
</blockquote></div></div><br>Again, hyperbole is not useful. This is a single commit, where I add functionality to a few functions for a single purpose.</blockquote></div><br>Matt, I was referring to the general "push as checkpoint" workflow rather than that single commit with the memory leak. While I think that patch could have been split into "generalize existing functionality" followed by "add new functionality", it's a bug that could have happened to anyone and is more reliably caught by proper testing.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra" style>I've given a lot of reasons why "push as checkpoint" is bad for everyone else working on the project. You have not explained how it helps so much.</div>
</div>