On Thu, Nov 19, 2020 at 01:25:27PM -0800, Junio C Hamano wrote: > The question most useful to ask at this point are to what name > (fixed? computed?) and what the transition plan would look like. Right, hence my statement that there are no "concrete plans." I've previously suggested that, should this change be implemented, it makes sense to couple it with another upcoming major compatibility break -- the sha1 deprecation. Perhaps we can start with the following: Currently: $ git init Initialized empty Git repository in /var/home/user/foo/.git/ $ New: $ git init Initialized empty Git repository in /var/home/user/foo/.git/ Initial branch: master Object format: sha1 Use --initial-branch and --object-format flags to specify other values. $ > > It is misleading in the context of git, because it implies that a > > branch carrying that name is in some way special compared to other > > branches (e.g. like "trunk" in the SVN world). In reality, the > > "master" branch is just a branch like all others (and can be missing > > entirely or have junk in it), so it really shouldn't be called > > "master". > > I find the above answer even more confusing, in the context of major > projects and hosting sites all moving to 'main'. If 'master' is > misleading for all the reasons stated in the above paragraph, 'main' > would equally be misleading. In other words, "It is just a branch > like all others, so it really shouldn't be 'master'" leads to "it > shouldn't be 'main' or 'primary', either". In my mind, there are important semantic differences between "main" and "master" that make "main" more acceptable. A town with a single road can reasonably call it the "main road." Similarly, a "mainstream" movement does not imply the existence of any other movements. Etc. -K
