Hi Denton, On Mon, 15 Jun 2020, Denton Liu wrote: > 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? My intuition matches your preference, and I have a strong preference for 3. It took some banging my head (not my HEAD...) against the code to convince myself that the patch I prepared for v3 is good: I managed to confuse myself what with all those submodules and clones in t7406. Ciao, Dscho
