[petsc-dev] Pushing non-working code

[Jed Brown]

On Sun, Feb 3, 2013 at 11:37 AM, Matthew Knepley <knepley at gmail.com> wrote:

> It is burdensome to cordon off work into separate channels, which may have
> to be updated between them. And
> 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.
> 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.
> It is not fair to say that I have not explained how this is detrimental,
> because I have reiterated this point several times
> only to have it dismissed out of hand.
>

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.)

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130203/459aa06c/attachment.html>