Add support for generating patch-ids
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.
- Allow approval after in-UI rebase or non-fast-f... (gitlab#216144 - closed)
- Do not reset approvals if rebase is performed (gitlab#337888 - closed)
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 like the ability to 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..)
One approach towards accomplishing this would be to add support for git patch-id
as a new RPC, allowing us (Rails) to request as needed, storing the result in the DB. This would allow us to quickly and efficiently compare the gestalt of a series of commits, rather than giant diffs, or even commits themselves (which potentially can be added, removed, squashed, etc during rebasing without impacting the resulting diff..)
(This was previously opened in gitlab#378954 (closed) and includes some initial discussions and feedback from Rails-side stakeholders here gitlab#378954 (comment 1149000248))