Best Practices for Reviewing Patches in the Git Project

manually mutate lines of new & existing tests to verify expected pass/fail behavior. You can use this information to verify proper coverage or to suggest additional tests the author could add. - When providing a recommendation, be as clear as possible about whether you consider it "blocking" (the code would be broken or otherwise made worse if an issue isn't fixed) or "non-blocking" (the patch could be made better by taking the recommendation, but acceptance of the series does not require it). Non-blocking recommendations can be particularly ambiguous when they are related to - but outside the scope of - a series ("nice-to-have"s), or when they represent only stylistic differences between the author and reviewer. - When commenting on an issue, try to include suggestions for how the author could fix it. This not only helps the author to understand and fix the issue, it also deepens and improves your understanding of the topic. - Reviews do not need to exclusively point out problems. Positive reviews indicate that it is not only the original author of the patches who care about the issue the patches address, and are highly encouraged. - Do not hesitate to give positive reviews on a series from your work colleague. If your positive review is written well, it will not make you look as if you two are representing corporate interest on a series that is otherwise uninteresting to other community members and shoving it down their throat. - Write a positive review in such a way that others can understand why you support the goal, the approach, and the implementation the patches took. Make sure to demonstrate that you did thoroughly read the series and understood problem area well enough to be able to say that the patches are written well. Feel free to "think out loud" in your review: describe how you read & understood a complex section of a patch, ask a question about something that confused you, point out something you found exceptionally well-written, etc. - In particular, uplifting feedback goes a long way towards encouraging contributors to participate more actively in the Git community. ==== Performing your review - Provide your review comments per-patch in a plaintext "Reply-All" email to the relevant patch. Comments should be made inline, immediately below the relevant section(s). - You may find that the limited context provided in the patch diff is sometimes insufficient for a thorough review. In such cases, you can review patches in your local tree by either applying patches with linkgit:git-am[1] or checking out the associated branch from https://github.com/gitster/git once the series is tracked there. - Large, complicated patch diffs are sometimes unavoidable, such as when they refactor existing code. If you find such a patch difficult to parse, try reviewing the diff produced with the `--color-moved` and/or `--ignore-space-change`

This section provides guidelines on how to effectively review patches, including verifying test coverage, providing clear and actionable feedback, and writing positive reviews that encourage contributors, as well as tips for performing reviews such as commenting inline and using local trees for context.