On Tue, Nov 17, 2020 at 04:47:56PM -0600, Felipe Contreras wrote: > On Tue, Nov 17, 2020 at 3:10 PM Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > > > > "Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > > > This is the big one. This changes the default of init.defaultBranch to main, > > > reflecting what many open source projects already did (which was followed by > > > GitHub, Azure Repos and others). > > > > Can we please not simply replace one hard coded branch name with > > another? > > I thought precisely the same thing. > > This should be easy to do if we make "origin" be a pseudo ref that > points to "origin/HEAD" (and we could introduce "origin/@"). Didn't we already do this long ago? refs/remotes/%s/HEAD is special in the dwim_ref() lookup: $ git rev-parse --symbolic-full-name origin refs/remotes/origin/master Or did you have something else in mind? I think I have occasionally hit spots where saying "origin" instead of "origin/master" does not work. I can't think of any offhand now, though (I thought perhaps "git checkout -b foo origin" or "git branch --set-upstream-to=origin", but both seem to work). > > I don't look in on the git list very often so perhaps I am missing a > > conversation where all of the details were thought through. If so > > please point me at that conversation. Otherwise can we please use this > > opportunity to come up with something that is actually better than > > naming the default branch main, rather than just something just as > > awkward whose only advantage is that people don't think it is > > politically incorrect this week. > > This is the thread: > > https://lore.kernel.org/git/CAOAHyQwyXC1Z3v7BZAC+Bq6JBaM7FvBenA-1fcqeDV==apdWDg@xxxxxxxxxxxxxx/ > > Unfortunately in my opinion the most important topics--like your > suggestion--were not even mentioned. Everyone focused on the wrong > thing (e.g. what would be a better name for "master"). There is another thread from the same time that contains quite a lot of discussion on logistics. This subthread in particular raises the notion of "let's try to minimize needing a special branch-name at all": https://lore.kernel.org/git/875zbrcpgh.fsf@xxxxxxxxxxxxxxxxxxx/ And indeed, it led to some other bug-fixes in improvements in the time since then: - submodule--helper was fixed to use HEAD from the remote as its fallback rather than a hard-coded "master" - fast-export --anonymize no longer treats "master" as special, but instead grew a flexible system for leaving some bits intact - fmt-merge-msg gained new options for configuring when it will print "into <branch>" So really all that is left is deciding what to do when: git init git commit -m foo is run. Obviously we added a config variable here, but we still fall back to a hard-coded name. One suggestion was to not use any name, and either require "git checkout -b some-branch" first, or commit onto a detached HEAD: https://lore.kernel.org/git/B4814F42-7AF8-4D80-93D4-FAF752C72F21@xxxxxx/ The simplicity has some appeal to me, but it's even less backwards-compatible than falling back to a new different name. I think Eric's suggestion of using the directory name as a default was not previously mentioned. I'm not sure I would like that myself (I find value in having a consistent "this is the main branch" name across different repositories, at least for my workflows). And it creates all of the same "every tutorial is now out of date" issues. But it is neutral. I wouldn't be opposed to seeing it as a configurable option. -Peff
