<!--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=424908) </details> <!--IssueSummary end--> Maybe since mid Aug 2023, Gitlab links to file or directory now always has a query string parameter `?ref_type=heads`. Example: ``` https://<myproject_path>/-/blob/master/.gitlab-ci.yml?ref_type=heads ``` We often paste the Gitlab URL in our Slack/Teams messages and internal documentation. The `?ref_type=heads` parameter is just noise adding no value to the link. Gitlab support had indicated that the `?ref_type=heads` was added to address issue 20526 [Impossible to browse a branch if a tag exists with the same name](https://gitlab.com/gitlab-org/gitlab/-/issues/20526) Would it be possible to have a user/group config somewhere to disable the `?ref_type=heads` workaround? As it never occurred to us to give an identical name to a branch and a tag. Also confirmed by a [comment](https://gitlab.com/gitlab-org/gitlab/-/issues/20526#note_215099290) on that same issue 20526 that it might not be a good idea: > using branches and tags of the same name isn't a pattern that works well. If you do the same thing locally, you'll end up with warnings like `warning: refname 'v0.0.1' is ambiguous` On github, there is no equivalent of `?ref_type=heads`.