2014-03-17 12:29 GMT-04:00 Michael Haggerty <mhagger@xxxxxxxxxxxx>: > This hunk uses the magic number "11" a couple lines later. Junio (I > think rightly) objected [1] to rewrites in these circumstances because > they make it even less obvious where the constant came from and thereby > make the complete elimination of the hard-coded constant *more* difficult. > > [1] http://article.gmane.org/gmane.comp.version-control.git/244005 Sure, I can understand that. I'll look through the hunks again with more context in the diff to try to look for more cases where magic numbers are used more than once. One of the goals of this revision is to minimize that, see the commit message. > In any open-source project it is important to optimize for the time of > the reviewer, because code-review is a relatively tedious task and is > therefore often the bottleneck for progress. Therefore I suggest that > you turn your approach on its head. Don't "remove the most > objectionable hunks" but rather *include only the best hunks*--the ones > that you can stand behind 100%, which you think are an unambiguous > improvement, and that the reviewer can accept without reservations. ... > It would be much better for you to submit only a handful of changes (or > even only one!) that is perfect, rather than throwing a bunch at the > wall and asking the reviewer to pick between the good and the bad. As > you gain experience and learn about the preferences of the Git project, > you will get a better feel for the boundary between > acceptable/unacceptable patches, and *then* you will be able to start > submitting patches closer to the boundary. I see. For v4, I will be more discerning as to what I include. I will try to keep the scope of future patches down and err on the side of caution when I review my own changes before submitting. Thank you for the *pointers. I'm going to give v4 a shot. It should be on the mailing list in an hour or so. Quint -- 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