Long branch name is hidden in collapsed dropdown
<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=35656) </details> <!--IssueSummary end--> ### Problem to solve The way long branch names were displayed on GitLab was brought up in [this issue](https://gitlab.com/gitlab-org/gitlab-foss/issues/62154) as well as [this MR](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/29069). While long branch names now appear on multiple lines, when the branch dropdown is collapsed, long branch names on some pages are still unreadable. This behavior shows up on the following views: * Repository -> Files * Repository -> Commits * Repository -> Contributors * Repository -> Graph * Repository -> Compare * Repository -> Charts ### Intended users Every user who uses GitLab and whose projects use multiple long branch names will run into this issue. ### Further details This screenshot shows how the initial problem was fixed in the issue referenced, but the collapsed bar is still not clear as to which branch it is referencing. ![Screen_Shot_2019-11-05_at_9.55.47_AM](/uploads/674a7ffb3f7b8d3374244b604201806d/Screen_Shot_2019-11-05_at_9.55.47_AM.png) This is not quite a bug as the customer can still figure out which branch they are on, but it will require them to open and close the dropdown any time they need that information. ### Proposal If modifying the collapsed dropdown does not make sense design-wise, we propose that we should put the branch name somewhere static no the page, perhaps similar to the Branch Comparison page: ![Screenshot](/uploads/76ab93ae0b1b54ab6083e3e0368d0db6/Screenshot.png) ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?--> ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. --> ### Testing We will want to make sure that long branch name display will work properly in all supported browsers. ### What does success look like, and how can we measure that? Readability and the ability for our customers to quickly differentiate between branches. ### What is the type of buyer? ### Links / references * https://gitlab.com/gitlab-org/gitlab-foss/issues/62154 * https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/29069 * https://gitlab.zendesk.com/agent/tickets/137014 (ZenDesk internal ticket)
issue