<!--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=273531) </details> <!--IssueSummary end--> The following discussion from !43290 should be addressed: - [ ] @kerrizor started a [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/43290#note_436379169): (+4 comments) > Small clarification - we will first pull from the _application_ default, then use the git default (which is _probably_ `master`) > > It feels.. complicated to explain, but WDYT? > > ```suggestion:-0+0 > = (_("Changes affect new repositories only. If not specified, either the configured application-wide default or Git's default name %{branch_name_default} will be used.") % { branch_name_default: fallback_branch_name }).html_safe > ``` There are two asks in the thread linked, and one more thing I think we should probably at least discuss: * Pull in the instance-level setting * Use the exactly correct wording for what the `application-wide default` should be called * Discuss potentially modifying the backend to always return SOME value in these settings See that thread for context on the first two items. For the latter, I think we're going to need some kind of "assurance" that the value in question (whether the instance setting or the group setting) always contains the setting "above" it by default. Or, we'll need some way to get the value that a `nil` value would fall back to. Take - for example - a situation where an admin has not set any of these values. - On the instance setting page, we can show `master` as the fallback, because we know the next step up the chain is `git`, which will provide that by default. - On the group setting page we begin to see the trouble here: We can check the instance setting and use that, or default it to `master`, but we've just explicitly codified that groups are always children of an instance (which may not [always](https://gitlab.com/groups/gitlab-org/-/epics/4257) be [the case](https://about.gitlab.com/company/team/structure/working-groups/simplify-groups-and-projects/)). Take it another level deeper - maybe we allow individual users to set this setting on their project: - Now for the project settings page we need to pull in both the instance level setting and any group level setting - accounting for the possibility that either are `nil` - and continue to hard-code Git's `master` value. ---- I think it makes more sense for there to be a single property available at all of these levels (application settings, group settings, etc.) like `default_initial_branch_name` that's **already hydrated** with the value that would be used. In application settings, that's the Git default. In group settings, that's the instance default. And so on.