The default branch name master in Git appears to derive the name from it's predecessor BitKeeper which had master/slave naming. Aside from the history of the default branch naming in Git, the historic term master is problematic.
@ericschurter we should not be the one creating the setting as this something that should be done by the source code team (and they are working on this afaik)
But we should see if we can start using that setting.
@cwoolley-gitlab do you think you have some resources for this in 14.0?
I think @andr3 might be the right person to guide us towards the implementation plan on this!
@cwoolley-gitlab do you think you have some resources for this in 14.0?
Looking at the requirements briefly (didn't look at the code), it doesn't seem like it contains any UI changes, but just uses the existing stored setting, so it seems like it should be fairly straightforward to implement.
Right, there isn't a user-facing impact to this unless you were to clone the wiki repo, right?
@rkuba my understanding of this issue was that it was wiki-specific and not directly tied to the effort groupsource code was tackling. My assumption was it would be moving away from a hardcoded master to use the default branch name configured for the instance or account.
@ericschurter my understand was that even if it's wiki specific it would take project settings into account. Otherwise I would find it odd if we care for separate settings for the wiki.
@rkuba Yeah, I think we're on the same page here. We don't want to introduce any configuration or settings specifically for Wiki. We just want to use the upcoming project setting in Wiki.
This means that every operation is forced to use master.
If we want to use the instance default branch, we have to instantiate the gollum_wiki passing the reference it has to use and, for that, we have to change every wiki RPC and pass a ref param indicating the reference that we want to use for the wiki (the default branch).
I've tried other alternatives, like using HEAD, or retrieving the branch from the HEAD in order to avoid changing all RPCs, but I couldn't make it work but maybe there is a way.
So, the options are, changing all Wiki RPCs(7) to include the new param or we can work to remove all RPCs (#36865 (closed)).
This last effort is bigger because we will need to make workarounds for several wiki behaviors but in the long run, it's what we want to achieve.
/cc @zj-gitlab in case you think we can solve this problem in a less disruptive way.
This means that every operation is forced to use master.
No, we're not? The HEAD file will be written to a new repository before there's any content when running git init. But, probably should change this in %14.0, Gitaly creates a repository with an init.Defaultbranch config value set to master (internal/git/repository.go). If that's updated to main, the HEAD will always dereference to refs/heads/main. I think this is the detail you're overlooking.
You can also update the HEAD reference to refs/heads/main right after repository creation. That should suffice too, and probably be easier for testing now @fjsanpedro
Nevertheless, the gollum rugged adapter (not Gitaly) uses the ref set in gollum-wiki to know which branch to write to. Therefore, from what I've seen, if we don't set the ref in gollum_wiki, even if HEAD points to the right branch, the rugged adapter will try to write to master.
I think, in this scenario, after rewriting HEAD and the gollum-wiki writing to master I was getting the warning warning: remote HEAD refers to nonexistent ref, unable to checkout., because the branch pointed by HEAD (main) hasn't been created.
When I was playing with the HEAD idea, I tried to instantiate the gollum_wiki using the ref inside rugged.head but the exception Rugged::ReferenceError was raised. I'll double-check this but maybe it's worth a call to pair on this issue.
before there's any content when running git init. But, probably should change this in %14.0, Gitaly creates a repository
This will remove a lot of burden for resources creating repositories and using different default branches.
Nevertheless, the gollum rugged adapter (not Gitaly) uses the ref set in gollum-wiki to know which branch to write to. Therefore, from what I've seen, if we don't set the ref in gollum_wiki, even if HEAD points to the right branch, the rugged adapter will try to write to master.
Sorry, I missed this part. And the code proves me wrong too, let me work on updating the default reference at Gitaly. Not sure if that helps, but is easy enough that you can test it next week.
The thing is that I'm not sure whether we should invest time on this issue @ericschurter given that our goal is to migrate the existing wiki create/update page RPCs to the existing Gitaly RPCs for regular repositories.
In the existing Gitaly RPCs we don't have this problem because we can specify in which branch we want to perform the changes so the existing problem will be solved. Nevertheless, migrating these calls is also a hard task, but the total time invested will be less than if we solve this issue and then we migrate the existing RPCs.
Ok @fjsanpedro thanks for updating the weight. Let's see where the capacity planning falls for 14.1 but I think I'd be ok pushing this one off. I want to support the change from master to main in any way I can, but given the fact that the branch names for Wiki are rarely seen anyway it's not a top priority.