Don't use DiffCollection for deltas
Conversation: gitaly#222 (closed)
What does this MR do?
Move towards deprecating the use of deltas_only diffs in combination
with Gitlab::Git::DiffCollection.
Are there points in the code the reviewer needs to double check?
Why was this MR needed?
DiffCollection is a 'fancy Array' which can limit diffs before presenting them to the user. We created it because large diffs can cause timeouts. After DiffCollection was introduced we also started using 'deltas only' diffs. These are diffs without patches: they show what files changed but they don't show the actual changes. For some reason we built deltas_only support into DiffCollection, even though they use none of the special capabilities of DiffCollection.
I think this is technical debt. It is making changes like https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11122 harder then they should be. With this change want to move towards deprecating 'deltas only' support in DiffCollection, and just handling deltas as a separate entity.
We cannot drop support for deltas_only in this change yet because there is code in gitlab-ee that depends on it. The right order is to convert all gitlab-ce uses of 'deltas only', merge into gitlab-ee, and then convert the gitlab-ee-only use cases. Then after that we can remove 'deltas only' support from DiffCollection.
Screenshots (if relevant)
Does this MR meet the acceptance criteria?
-
Changelog entry added, if necessary -
Documentation created/updated -
API support added - Tests
-
Added for this feature/bug -
All builds are passing
-
-
Conform by the merge request performance guides -
Conform by the style guides -
Branch has no merge conflicts with master(if it does - rebase it please) -
Squashed related commits together