Hi, Junio C Hamano wrote: > demerphq <demerphq@xxxxxxxxx> writes: >> kind of confusion. Consider how this conversation goes for us: >> >> A: "No you need to fetch trunk from the remote, then you need to merge >> it to your local trunk and then push it to the master trunk". >> B: "Ok." > > Hmph, why isn't the last one "trunk trunk"? > >> Similarly when the perl project migrated to git we renamed "master" to >> "blead" to reduce the possibility "master master" confusion. > > Or put it differently, "your local master? remote master? or the > primary master?" would be a way to state the phrase A asked in the > example without renaming the name for the primary branch to 'trunk'. > > What I am trying to get at is, after changing the name that is given > by default to the primary branch in a newly created repositories by > "git init" to 'main' (which I am OK with, and it seems that the > major projects and repository hosting services will be doing anyway > with or without getting themselves in this discussion on this list), > wouldn't we risk the same "master master" confusion caused by and to > those newer users who learn 'main' is the word given to the primary > thing? I think Yves's point is that when the tool you are building has a component named $FOO, it's confusing to also have a branch named $FOO. So for example, if we were in the habit of calling main.c 'main' and frequently referring to it, this could be a reason to avoid also using 'main' as the name of the primary development branch. When someone says "that's fixed in main", it could prompt a moment of confusion --- did they mean that there's a fix in main.c, or that the fix has landed in the main branch? In particular when building distributed systems, historically it has been common to have one of the components being built be named 'master'. Fortunately in this context, I haven't heard 'main' used frequently that way. (I suppose it helps that main() functions are often short.) Thanks, Jonathan
