Here's a narrow question which we should agree an answer to: Is it OK to merge a pull request only having reviewed the diff? (I am thinking of relatively small changes here, i.e. typical pull requests)
In the past I have generally reviewed every commit, in case there are problems (e.g. backdoors!) hidden that might be hit when somebody does a git bisection searching for a bug. However, this may be overly paranoid. It can be avoided completely: If a pull request is more than one commit, and the commits aren't helpful to the review process, then the person doing the merge can either squash them into one commit, or request that the author does so. Hence we get a clean, reviewed history, without having to review every commit as bugs are added and then removed. In practice, for straightforward pull requests, one commit will generally be better anyway.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
