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'.
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'.