That's not the case. Anyone can express their view on what the state of a repository should look like by issuing a repo announcement event with a matching identifier. They can either issue state updates themselves, or list other pubkeys as 'maintainers'. This effectively delegates or entrusts these pubkeys to update the state, and  which git server(s) to get the data from, on their behalf.

When you clone a nostr repository you choose one pubkey you trust and follow their state. 

For most repositories, there will be a small number of maintainers who all list each other and permissions will appear much like a normal centralised solution. But its actually much more interesting and powerful.

Take a project like bitcoin-core. nostr:nprofile1qqsqfjg4mth7uwp307nng3z2em3ep2pxnljczzezg8j7dhf58ha7ejgprdmhxue69uhhyetvv9ujucnfw33k76twwpshy6ewvdhk6qguwaehxw309ahx7um5wghx6at5d9h8jampd3kx2apwvdhk6qg5waehxw309aex2mrp0yhxgctdw4eju6t0udvd2m or nostr:nprofile1qqsve2jcud7fnjzmchn4gq52wx9agey9uhfukv69dy0v4wpuw4w53nqpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9uk3h9ux, who are knowlegable and respected in the community could create a repository announcement that lists maintainers they trust. They practically wouldn't have to do anything to maintain the state but could elect to change their list of maintainers at any time if they felt the movement was better served by a different set of maintainers. Everyone who chose to trust their pubkey for the repository state will now be served the state issued by their new selected maintainers.

This reduces the level of trust required in the actual maintainers by just a little and spreads it throughout the community. It certainly means there is no official source of truth.

Additionally, the use of the optional `maintainers.yaml` file, embedding the list of reccomended maintainers in the commit history, can act as a distributed concseus mechanism but thats a topic for another post.