> I also think it becomes a problem when you're doing these smaller code reviews as the blog post is recommending; if you're doing bite sized chunks of code, it

> I also think it becomes a problem when you're doing these smaller code reviews as the blog post is recommending; if you're doing bite sized chunks of code, it's really easy to lose context and overlook things which might be performance bottle necks. Absolutely. In fact not just performance bottlenecks but other things too. Worse still is if a commit is not a discrete fix, then you have to review a set of commits, possibly editing and re-editing the same code, together. Additionally I imagine I would have less trouble with a single 100 line commit than I would with 100 one-line fixes. Context tracking has overhead. the single best rule is not to worry about size of the commit but ensuring that the commit is self-contained and tested (generally, not necessarily perfectly) before being committed. Commit things so that they are discrete and reviewable chunks and worry less about size.