On Wed, Jul 14, 2010 at 18:06, Brock Peabody <brock.peabody@xxxxxxxxx> wrote: > Hi Avery, > > Avery Pennarun <apenwarr <at> gmail.com> writes: > >> For an open source project, where most contributions are by volunteers >> and need to have their patches reviewed multiple times before >> submission - and frequently, more patchsets are rejected than applied >> - this works reasonably well. For a company where (in my experience >> at least) most people's patches *are* applied, and the ratio of >> reviewers to coders is much lower, that's much less workable. And >> unfortunately the elegant looking multiple-signed-off-by or acked-by >> lines don't work so well for that. > > I think you've hit the nail on the head here. In our environment, commits are > frequent and signoffs prompt. Revisions are very rarely rejected, and will > never pass through more than one reviewer except in extreme cases. Contributors > will have little tolerance for per-commit time or complexity overhead incurred > from the process. Well, consider that even if you push most patches through, the peer review you get from having a setup similar to Git's own might very well be worth it. Everyone makes mistakes, having a second set of eyeballs to look at your code eliminates a lot of that. That may not be acceptable to your corporate culture, but consider that most big corporations (e.g. Google) do detailed code review before anything gets commited to the master repository. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html