4 ms·
In theory, yes - if the underlying repo changes, code review should start over. In practice though, it's a terrible idea ;) Part of code review is to ensure th
by kiallmacinnes 8y ago
In theory, yes - if the underlying repo changes, code review should start over. In practice though, it's a terrible idea ;)
Part of code review is to ensure the code "fits" with all other merged code - so a re-review is "needed" when other changes merge. E.g. if I merge a refactor that changes everything from Pascal case to 100% SHOUTING, reviews now need to take this into account.
In practice, this doesn't happen - it's way too much effort for far too little value.
- jen20 8y ago> if I merge a refactor that changes everything from Pascal case to 100% SHOUTING, reviews now need to take this into account. To be fair, if you get away with merging that refactor, the review that needed more attention was of that refactor ;-)
- thedufer 8y agoI think the trick is to only re-review the areas that had merge conflicts, and to do the re-review aware of both the changes you already reviewed and the changes that caused the conflict. Merge conflicts, even in big code refactors, are fairly rare, so this ends up not being much additional work in practice.