<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 3, 2013 at 11:37 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_extra">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></blockquote></div><br>It does force you to think more clearly about which features are distinct, but not necessarily up-front (you can edit history as much as you like before pushing). If the "separate features" end up interacting, you _should_ merge (perhaps without pushing yet) because it has semantic meaning. I'm complaining about semantically meaningless merge-push or rebase-push to petsc-dev. (Push to your own private branches if you want that.)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra" style>I'm suggesting that when you push to petsc-dev, the patches should be organized to be understandable by someone reading them. Anything less is wasting the time of other people working on the project. The commit graph should have some semantic meaning because its purpose is to be read by people, not just as a mechanism for getting code onto other people's computers.</div>
</div>