debian-mirror-gitlab/doc/user/admin_area/diff_limits.md

46 lines
1.8 KiB
Markdown
Raw Normal View History

2019-09-04 21:01:54 +05:30
---
2020-06-23 00:09:42 +05:30
stage: Create
group: Source Code
2021-02-22 17:27:13 +05:30
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2019-09-04 21:01:54 +05:30
type: reference
---
2021-03-11 19:13:27 +05:30
# Diff limits administration **(FREE SELF)**
2018-12-05 23:21:45 +05:30
2019-09-04 21:01:54 +05:30
You can set a maximum size for display of diff files (patches).
2021-06-08 01:23:25 +05:30
For details about diff files, [view changes between files](../project/merge_requests/changes.md).
2019-12-04 20:38:33 +05:30
2019-09-04 21:01:54 +05:30
## Maximum diff patch size
2021-03-11 19:13:27 +05:30
Diff files which exceed this value are presented as 'too large' and cannot
be expandable. Instead of an expandable view, a link to the blob view is
2019-09-04 21:01:54 +05:30
shown.
2021-03-11 19:13:27 +05:30
Patches greater than 10% of this size are automatically collapsed, and a
link to expand the diff is presented.
This affects merge requests and branch comparison views.
2019-09-04 21:01:54 +05:30
2021-03-11 19:13:27 +05:30
To set the maximum diff patch size:
2018-12-05 23:21:45 +05:30
2021-06-08 01:23:25 +05:30
1. Go to the Admin Area (**{admin}**) and select **Settings > General**.
2019-09-04 21:01:54 +05:30
1. Expand **Diff limits**.
1. Enter a value for **Maximum diff patch size**, measured in bytes.
2021-06-08 01:23:25 +05:30
1. Select **Save changes**.
2018-12-05 23:21:45 +05:30
2021-03-11 19:13:27 +05:30
WARNING:
This setting is experimental. An increased maximum increases resource
consumption of your instance. Keep this in mind when adjusting the maximum.
2019-09-04 21:01:54 +05:30
<!-- ## Troubleshooting
2018-12-05 23:21:45 +05:30
2019-09-04 21:01:54 +05:30
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
2018-12-05 23:21:45 +05:30
2019-09-04 21:01:54 +05:30
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->