Hi Dscho, On Mon, Jun 15, 2020 at 12:26:03AM +0200, Johannes Schindelin wrote: > > For example, my vim plugins are submodules in the '~/.vim/bundle' > > directory. When I want to update them, I run: > > > > git submodule foreach 'git remote update && git reset --hard origin/master' > > > > With this change hitting a Git release, more and more people would call > > their main branch different names they like. So what is the recommended > > way to do something like this now? How do I checkout the tip of the main > > branch? How do I push to the main branch? How do I pull from the main > > branch? And so on... > > ... has less to do with a new Git release, but more with the decision of > an existing project to change their main branch name. > > That's something users already had to deal with, of course. For example, > projects switching to the Git Flow model will start to use the main branch > name `development`. I brought this concern up in a parallel thread but I'll bring it up here too since it's relevant. Currently, in the .gitmodules file, if the branch is not specified, it defaults to 'master'. When I want to update my vim plugins, I run `git submodule update --remote` which pulls in all of my submodules' 'master' branches. By convention, a lack of `branch` key in .gitmodules conventionally means 'master'. With your change, it becomes the value of git_main_branch_name(), which is fine for now. However, if this value changes to something else, then when I update my Git, suddenly `git submodule update --remote` will be broken for me as all of the new repositories that I pull will be for an incorrect (and possibly missing) branch. This leaves us in a scenario where one developer running an older version of Git would have submodule updates work perfectly fine while a developer with a newer version would have it suddenly broken. This might be hard to debug, especially for someone who doesn't follow the release notes around Git and doesn't realise why the default has suddenly changed. This problem gets much worse if we allow the main branch name to be configurable as then the *private* configurations that a developer has may have an effect on the *publicly visible* behaviour of a repository. I think I see three possible solutions to this: 1. Special case 'master' in submodules to retain backwards compatibility. I don't think this is very appealing as if the change is made to use another default branch name, then the "default" branch for submodules would be "master" even though the new default everywhere else would be different. And in the future, someone who doesn't know the context behind all of this would be very confused where there are two different default branch names. 2. Disable 'update --remote' support for submodules that don't specify a branch. If Git detects that a branch key is missing when trying to do an 'update --remote', it should just quit out and refuse to do anything. Of course, this a very backwards incompatible change and it would require several release cycles to implement where we warn users about this impending change before we actually make it happen. 3. Make 'update --remote' get HEAD. I argue that this is how it always should've been implemented but, alas, I can't go back in time and fix it. Regardless, it might be good to flip this to be the default if we're going to be making the change anyway. Unfortunately, this suffers from both the problems of 1 and 2. As with 1, we'll end up in a situation where users with different versions of Git may experience different behaviours given the same public repository and I think this is definitely undesirable. With 2, this change will also require a long deprecation period which I don't think it compatible with how people seem to want the default branch switch to happen this release. So I dunno. I think my opinion leans on not changing the default branch at all. Since it seems like the consensus is generally that it _will_ change, I think I would prefer options 3, 2 and 1 in that order. Thoughts?
