Hi Pratyush,
On Mon, 15 Jun 2020, Pratyush Yadav wrote:
On 10/06/20 09:19PM, Johannes Schindelin via GitGitGadget wrote:
quoted
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