Thoughts on Code Coverage Scope in Code Review

Our current code review scope filters commits by branch and by day. Does that create duplicate reviews in practice?

When we target a single branch—say, a sprint branch—and filter for yesterday’s commits, the list includes merge requests (MRs). Each MR is effectively a commit that bundles earlier commits. An MR created on the 5th might contain code written on the 4th.

Do We Keep Seeing the Same Code?

1. You’ll notice commit dates outside the target review date because an MR on the 5th can include diffs from the 4th.
2. Reviews focus on diffs. Once earlier code merges into the branch, the next day’s diff excludes it. So the same code isn't reviewed twice.

Conclusion

The current code review scope doesn’t create duplicate coverage.

Notes

1. An MR appears as a single commit, but the diff folds in N commits from other branches tied to that MR.
2. If the MR has conflicts, the merge commit may include diff adjustments that exist only in that commit.
3. The MR’s commit date differs from its constituent commits—the history is linearized.
4. Git orders entries by push date, but the list shows commit dates.