Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> writes: > - having a branch named "master" is already not required, so any > existing software that expects there to always be a "master" branch is > already broken and wouldn't get any more broken by the move away > towards more descriptive terminology The above is mostly true but not entirely, I have to remind you. There certainly is the concept of the primary branch in each repository. With the current version of Git, it is hardcoded to be the 'master' branch, and we are going to make it configurable with a configuration variable [*1*]. There are a few examples that the primary branch is treated specially: - When merging into the primary branch, the auto-generated merge message is different from a merge into any other branches. This was because most of the merges, especially in early days of Git, were into the primary branch (there weren't many cross-branch merges made) and we did not want to see repeated "Merge X into 'master'", "Merge Y into 'master'", etc.---we just say "Merge X", "Merge Y", etc. when merging into the primary branch. - "gitk" gives preferencial treatment to 'master' when there are too many references it has to choose which ones to make visible. - "git fast-export --anonymize" redacts the name of all the branches, but the name of the 'master' branch is left intact in its anonymized output (which is done in order to make the primary line of work identifiable even in the redacted output stream). There may be others. Software that assumes that 'master' is special is *not* broken as you stated (we will break them when we allow changing the default---that is the cost those of us who are working on the transition plan thought worth paying). The concept of "there is one thing that is special among others" can serve useful purpose. It of course opens a different can of worms ;-) Even though we can please master-slave-haters by moving away from the particular word 'master', those who cannot stand the very idea of one thing being special among others will not be satisfied (and we shouldn't even try to please them, IMO). [Footnote] *1* There is a related but separate concept of the "default name" for the primary branch in newly created repositories, which also is hardcoded to be 'master'. We are going to make it configurable, too. This controls the name used by "git init" (possibly we will also add a command line override "git init -b name" to countermand the configured default) and "git clone" (which tries to use the name of the branch pointed at by HEAD of the other side but has to fall back to something when it cannot figure it out).
