This adds patch versioning support for merge requests by generating a new MergeRequestDiff entity each time a MergeRequest#target_branch is updated (via git-push).
This feature, aims to greatly improve code review by allowing the reviewers to see the progress of the patch across updates.
A reviewer could approve most changes in a patch version and then just do a interdiff with future versions instead of having to review the entire patch again.
This workflow is inspired by ReviewCode and derived from my comment on: http://feedback.gitlab.com/forums/176466-general/suggestions/3896541-preserve-conversations-on-merge-requests-after-com
Currently, only diffs are displayed, not interdiffs. But you can manually get an interdiff by downloading both raw diffs versions to compare; for example, to compare versions 1 and 2 of a merge request you would do something like this:
interdiff \
<(curl -s -H 'Cookie: ....' 'http://your.gitlab.installation/<group-name>/<project-name>/merge_requests/<mr-iid>.diff?version=1') \
<(curl -s -H 'Cookie: ....' 'http://your.gitlab.installation/<group-name>/<project-name>/merge_requests/<mr-iid>.diff?version=2')You could also pipe the interdiff through colordiff to get a better output.
I'm currently test driving this feature in my daily workflow and would really like know what you think about it too.