Hi Taylor, On Wed, 10 Jun 2020, Taylor Blau wrote: > On Wed, Jun 10, 2020 at 09:19:21PM +0000, Johannes Schindelin via GitGitGadget wrote: > > A growing number of open source projects aims to avoid the branch name > > master due to its negative connotation. See [1] for an existing discussion > > on this. The links [2], [3], and [4] describe community-driven ways for > > users to rename their default branches or use template edits to set a new > > default branch name. > > > > [1] > > https://lore.kernel.org/git/CAOAHyQwyXC1Z3v7BZAC+Bq6JBaM7FvBenA-1fcqeDV==apdWDg@xxxxxxxxxxxxxx/ > > > > [2] https://twitter.com/mislav/status/1270388510684598272 > > > > [3] > > https://www.hanselman.com/blog/EasilyRenameYourGitDefaultBranchFromMasterToMain.aspx > > > > [4] https://github.com/ethomson/retarget_prs > > > > By necessity, existing repositories require a lot of manual work to move > > away from that branch name, but it should be much easier for new > > repositories. > > This is (somewhat) orthogonal to the topic here, but I wonder if we > could be doing anything to make this easier for users. > > Could servers remember that a branch has ``moved'' and alert users as > such when they pull? Even better, it would be nice if this alert from > the server could allow clients to automatically rename their refs > appropriately so that this transition is as easy as possible, even for > existing repositories. I would _love_ to have `git fetch origin master` work, spitting out a message `the main branch name changed to [...] please update your configuration`. And then maybe an easy way to update the configuration (`git remote set-main-branch <nick> <refname>` might make sense). As you say, it is orthogonal to this here patch series, but definitely related in spirit because we _want_ to make it easier for users to move away from the current main branch name. > > This patch series allows overriding the branch name being used for new > > repositories' main branch. The main way to do this is the new > > core.defaultBranchName config option. This first patch was contributed by > > newcomer Dan Goodman-Wilson. Thanks for the contribution! > > Welcome, Dan! This is a fantastic first contribution, and I would be > honored to help and move this forward in anyway that I can. Sorry, my typo: it's Don, not Dan ;-) > I should note that I am technically "out of office" (which normally > wouldn't mean much, but this time means that I am on a road-trip, and so > am only at my computer infrequently). I am catching up on just a few > emails here, but I'll be able to help out more (and would be honored to > do so) once I am really back next Monday. Well, go back enjoying your road trip! :-P See you on Monday. > > The other patches follow other places where "master" is hard-coded and use > > the new git_default_branch_name() method to consume the config option before > > falling back to "master". > > > > The last patch updates documentation only after the config option is ready > > to apply to all of these scenarios. > > > > 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. > > Provided that the eventual plan is to seriously evaluate a name other > than "master", I think that this is a good way forward that clears the > way for us to make this change easily, without forcing us to come to a > conclusion on what name will replace "master" today. That is exactly the intention of this patch series. I _do_ want to put my weight behind changing the default. Obviously, this will take quite a bit of time (but maybe less than I originally thought, as we are only talking about changing the default for _new_ repositories). Even if this endeavor fails, though, this here patch series will be good to have. > For what it's worth, I am completely in favor of abandoning this term. > My colleagues at GitHub (as has been mentioned previously on the list) > are in favor of this as well, and it is my understanding that other > providers feel similarly. >From what I read at https://gitlab.com/gitlab-org/gitlab/-/issues/221164, GitLab is on board, too. > I would be in favor of any non-offensive name that we can reach > consensus on. "trunk" sounds nice to me, but I think that it may cause > problems for non-native English speakers, so perhaps "main" or > "default" would suffice (maybe "main" is better, since it retains muscle > memory for the first two characters without being offensive--at least, > as far as I can tell. If I am wrong, please correct me and we should > consider something else). My personal preference was "default" on Monday, and "main" ever since. > All of that said, I can't emphasize enough how little I care about > *what* name we replace "master" with, so long as it is (1) replaced with > a non-offensive term, (2) that that change is done uniformly throughout > the "Git Ecosystem" and (3) that the community can reach consensus on > the new term in a respectful, appropriate, and considerate way. I only > provided a few suggestions to get the conversation flowing, although I > suspect that my help isn't needed there. Indeed. I laid out the patch series in such a way that we should be able to pick a different default main branch name than "main", even if it is my current working hypothesis that this will prevail. As I said, my preference was "default", and that's how my big patch series looked like, so I know how much work it is to change to a different name (because I changed it to "main"). It is quite a bit of work, but manageable. Ciao, Dscho
