[there_the_and]

> I picked the names "master" (and "origin") in the early Git tooling back in 2005.

> (this probably means you shouldn't give much weight to my name preferences :) )

> I have wished many times I would have named them "main" (and "upstream") instead.

> Glad it's happenning @natfriedman

https://twitter.com/xpasky/status/1271477451756056577?s=21

[wayneftw]

You left out the most relevant part:

> Out of curiosity, why 'master'? What was it meant to convey? 'Master' as in 'original' or as in 'owner'? [0]

the reply:

> "master" as in e.g. "master recording". Perhaps you could say the original, but viewed from the production process perspective. [1]

[0] https://twitter.com/yawaramin/status/1272237126474752005

[1] https://twitter.com/xpasky/status/1272280760280637441

[amyjess]

For what it's worth, I have to reactions to that, both positive:

1) I came from an SVN background and only switched to Git because I started working at companies that used it. I still prefer SVN's aesthetics (and I wish I had more opportunities to use Mercurial), so I would much rather have 'main' or 'trunk' than 'master'.

2) At my company, my team uses the forking workflow (i.e. we do all our work in our own forks and then submit PRs to merge into the repo on the central server). Whenever I clone and fork a repo, I always nuke the 'origin' remote and create two new ones: my own fork, which I name after my AD username at my company, and the repo on the central server, which I name 'upstream'. That way, whenever I pull or push, I don't have to worry about mindlessly pushing or pulling 'origin' and accidentally touching the wrong repo: if I accidentally do so, I'll just get an error. So I am very, very much used to pulling from 'upstream'.