Project with many branches can lock server running "git branch --contains XXX"
What does this MR do?
When displaying a commit, we do a git branch --contains XXX
to get the branches and tags that are related to this commit. However, when there are thousands of branches or tags, this query can take a long time, and peg a cpu core. This could cause severe performance issues.
We now check how many branches or tags are available, and do not perform the query if there are too many.
Are there points in the code the reviewer needs to double check?
no
Why was this MR needed?
This was reported by a customer: ZD: https://gitlab.zendesk.com/agent/tickets/82394
Screenshots (if relevant)
With no branches or tags to show
With branches or tags to show:
When no branches or tags are available
Does this MR meet the acceptance criteria?
-
Changelog entry added, if necessary -
Documentation created/updated -
API support added -
Tests added for this feature/bug - Review
-
Has been reviewed by UX -
Has been reviewed by Frontend -
Has been reviewed by Backend -
Has been reviewed by Database
-
-
Conform by the merge request performance guides -
Conform by the style guides -
Squashed related commits together
What are the relevant issue numbers?
Closes #37824 (closed)
To do
-
Style unavailable branches/tags message according to: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14812#note_44868972 -
Fix specs