Generate fingerprints/signatures for merge_request_diffs
Users who interact with MR pages are often distanced from the actual mechanics of git that underlie the diffs, which is a strength of our product. However, by gently obfuscating the concept of commits and branches, we find users are often confused about the implications of those concepts. One area this arises in particular is approval rules behavior around rebases. Often users want approval rules to be reset when new code enters the diff; this is a fairly basic security requirement, as it helps ensure that unreviewed/unapproved code doesn't enter an MR.
This sensible behavior is broken in a situation where a rebase occurs, as git generates new commit SHAs, which look like "new code" to our app. While we can work around this with rebase commit SHAs and disabling approval rule resets for UI-generated rebases, if someone rebases via the command line, we have no way of detecting that -- we only see new commits coming in via the push. This would lead to a disjointed UX and rebase changes behavior depending on which execution method is chosen.
The real question we're attempting to answer is "has a meaningful, programmatic change been made in the diff" which is only detectable by comparing merge_request_diff
data. Rather than attempt to compare 2 diffs themselves (potentially quite large text blobs) we would instead generate a representation of the raw diff, allowing us to compare for actual changes in the code. This would allow us to detect not only for the case of "this is just a rebase, no need to reset approvals" but potentially to trigger (or not..) additional management behavior in the review cycle (such as notifying previous reviewers that a change has been made..)
This representation could be a SHA (or some other form of hashing, such a minhash) and could be on either the merge_request_diff
as a whole, or even on individual files, opening a possibility for selective re-review via CODEOWNERS ownership (another oft-requested feature..)