Hi Pratyush, On Mon, 15 Jun 2020, Pratyush Yadav wrote: > On 10/06/20 09:19PM, Johannes Schindelin via GitGitGadget wrote: > > > This series DOES NOT change the default automatically, but only provides an > > opt-in mechanism for interested users. It also presents a way forward for > > such a transition, if and when we decide to do so. Specifically, the new > > GIT_TEST_DEFAULT_BRANCH_NAME environment variable could be used to update > > test scripts on an individual basis instead of all-at-once. > > Many people have expressed reservations against this change. >From what you wrote below, I take it that you are not talking about this patch series, nor the follow-up one(s) to change the default main branch name for new repositories. > One argument from those in favor of this change is that it doesn't > affect you if you don't care about the default branch name. You can just > go on using 'master' for all _your_ repos. I'd like to highlight the > "your" here. Sure, I can keep on using 'master' if I so prefer, but I > don't just use my repos. I also pull repos from other people, and I have > no control over what they call their main/primary/master branch (I'll > use "main" for the rest of the email). The cost here is that people now > need to update their scripts and workflow to account for other people's > naming preferences. This talks about the scenario where a project you use decides to change their main branch name. While this is a scenario that my patch series tries to support (by introducing the concept of `core.mainBranch`), it is not something my patch series _causes_. All _this_ patch series does is to _allow_ changing the main branch name (manually) in an existing repository, and to change the default main branch name to use in new repositories. Even the follow-up patch series I plan on contributing that changes the hard-coded default for the default main branch name to use in new repositories won't affect any existing repository. So I think this example... > 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`. GitHub Desktop changed their main branch name to `development`, and it did not require any new Git release. GitHub CLI changed their main branch name to `trunk`. Chrome and node.js stated their intention to change their main branch name to `main`. And https://github.com/microsoft/git uses `vfs-<version>` where `<version>` corresponds to the Git (for Windows) version on which it is based, therefore the main branch name changes whenever there is a new Git version. These challenges have existed for every project that chooses to change their main branch name, for whatever reason. In other words, I think you are talking about a challenge that is orthogonal (if related, on a high level) to the subject this patch series tries to address. Ciao, Johannes
