6
\$\begingroup\$

Most open source projects accept updates via patch files.

And any non trivial fix is going to be spread across multiple files and thus take up lots of space in the standard format.

Do you think supplying a patch file for review would be beneficial or too little information? The patch file will give context and provide the original plus the new code for inspection.

\$\endgroup\$
6
\$\begingroup\$

I guess it really depends. If the patch is able to give enough context, it might be useful. I'd be more inclined to say to include the entire chunk of code that you are touching so that it can be looked at in its entirety.

\$\endgroup\$
1
\$\begingroup\$

I'd say try it.
If we end up not liking it, we'll update the rules.

I like the idea of reviewing a patch file, but reading through a diff file could be messy and as Mark Loeser pointed out, there may not be enough context to review the code adequately.

The reason I like the idea of reviewing a diff, is we can see the original problem and your solution to the problem, and then we could review whether or not you provided an optimal solution.

\$\endgroup\$
1
\$\begingroup\$

I think that reviewing patches would be a bad idea. Since answers will likely suggest changes to the code, they will be, in a sense, a patch on a patch, and that would be nasty.

I suggest posting the question with the relevant excerpts of the "after" code to be reviewed. Optionally include the "before" code, provide a brief explanation of the changes, and tag the question as . Reviewers can diff the "before" and "after" code on their own if they want.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .