<div dir="ltr">On Sun, Feb 3, 2013 at 12:31 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"><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><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><div class="im"><br>Again, hyperbole is not useful. This is a single commit, where I add functionality to a few functions for a single purpose.</div></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">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>
</blockquote></div><br>It is burdensome to cordon off work into separate channels, which may have to be updated between them. And</div><div class="gmail_extra">you can say that VC has features to do this, which is true, but it is simply wrong to assert that they entail no cost.</div>
<div class="gmail_extra">You consider this cost low, but that does not mean that I do as well. When I raise this as an objection, you ignore it.</div><div class="gmail_extra">It is not fair to say that I have not explained how this is detrimental, because I have reiterated this point several times</div>
<div class="gmail_extra">only to have it dismissed out of hand.</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>