ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes: > "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? > > Having a blessed name for the initially created branch continues to > imply the branch has special significance. As the initially created > branch does not have special significance can we please do > something that does not imply that? I personally am fond of this line of "let's not treat one single thing any special among others" approach, but I think the way people use the initially created branch tends to make it special at the end of the day. While the project is still in its infancy, you may use that as the only branch until the tree of the project starts to take its shape, perhaps with subdirectories dedicated to sources, documentation, and overall build procedure, etc. Then you may start to fork different branches to work on topics that last more than one commit's worth of time and then it is likely you'd use the initially created branch as the integration branch, until you start to need the second and third integration branches. Like it or not, the primary integration branch would inevitably end up being something more special than others, and it is likely that using the initially created branch for that purpose would be the most convenient. There however may exist two or more equally significant branches, not just one special one, though, but it is reasonable to have at least one special one. I think using some word that is derived from $(basename $(pwd)) as the name of the initial branch may be a more reasonable choice than using any single word that tries to fit everybody (which will *not* exist). When a user says "git init tinyshell" to start a project to create a tiny shell, "tinyshell" may be one reasonable choice to refer to its primary integration branch. Everything that goes into it will become part of the tinyshell project. But if there is a woke-safe word that can refer to "the primary integration branch", calling the initially created branch with that word by default is also equally a reasonable approach. I personally do not like the word 'main' used as such, but the rest of the world seems to be moving in that direction, so being consistent with them would help users who want to do mkdir project && cd project git init ... some workflow specific 'git config' here ... git remote add $URL origin git pull origin and have it be an enhanced equivalent to git clone $URL project The latter will try to find the name used for the primary branch on the other side and use the same name; the former would not work that way, but if "git init" uses a fallback default that is most common, it would hurt less. In any case, the updated version of these 28 patches no longer has the final "switch the fallback default to 'main'" step, and the good thing is that the other 27 patches will help us moving in any direction. If we choose to dynamically derive the initial branch name, these steps make sure that such a change won't break our testsuite. > Instead of having a fixed name across all repos for the initially > created branch can we instead use the directory name of the repo for the > branch name? > > Advantages: > > - The branch name that is somewhat meaningful to the creator of the git > repo. > > I have at least two repos where I wound up doing this by hand. So at > least for me it is something I am doing anyway. Direct "other side" of the coin is that the name meaningful to the creator may be different from project to project, so those who want to try peeking projects that are so far unknown to them will have to guess what that meaningful thing is. When visiting a random github repository and presented by 47 different branches, it would be more helpful for such a visitor to have a reliable "this is likely to be the primary integration branch" cue. Not having a convention is worse than having a convention some folks may find suboptimal from usability's point of view. > - Tools can not hard code the name of an initially created branch and > expect it to work. Cannot? Is this a dogmatic declaration? If tools that are meant to work with variety of projects with a single "special" branch and do things relative to that special branch (e.g. perhaps the special branch is the primary integration branch, and the tool may list commits that are not yet in that branch), a toolsmith has multiple choices. The tool can take the name of the "special" branch from the end-user to be most flexible, of the tool can hardcode the most commonly used name for the "special" branch to be out-of-the-box useful for majority of projects. Most sensible folks may do the former, but I do not think the latter is a bad choice. And even those who do the former has to fall back to some hardcoded value when the user didn't give the name of the "special" branch, because end-users are greedy and will demand such a "convenience" feature, saying "in most repositories, this name is commonly used for the 'special' branch---why force us to type the same thing?"
