On Tue, Feb 21, 2012 at 7:43 AM, Christopher Swenson <ch...@caswenson.com> wrote: > Well, I believe that gerrit was designed with the Google philosophy in mind, > so I would assume that this would mean that the software must run after each > commit that is mailed out. (This is sort of equivalent to the way patches > work now, as they cannot be committed unless all tests pass.) > > There are some exceptions, naturally: when large, new sections of code are > being developed, it is not unheard of to accept commits that don't actually > work.
It gets a bit fuzzier when there are multiple authors on a single feature, spread out through time. I think this is more common for a project like Sage (lots of very-part-time contributors). It can also be handy to spread out history into smaller or logical chunks (e.g. big automatic renames/file moves, and then manual fixups, where the former might not give a consistant state but is easy to review because it's just the result of a sed script). I do, however, like the model of iteratively working on a feature, including incorporating peer feedback and fixes, adn then squashing the history down into a single coherent commit at the end. Perhaps we could require that every state of the main line be consistant, and if it's worthwhile to preserve inconsistent history we merge it as a branch rather than rebasing. - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
