Additionally, I don't think sense 29 actually makes sense here. A "master copy" is immutable. Once somebody burns a master record, that's it — you're done. You make copies from that one because it is deemed "correct" in some sense.
But git branches are not immutable; they are able to be added to at any point. The master branch can be interpreted as collating the work done by all of the other branches: non-master branches do some work, then it gets merged back to `master`. Which means... the master branch is coordinating work done in other branches. And, in many git workflows, work on the master branch itself is discouraged, meaning almost all work is done in separate branches and then the master branch is used to accumulate that work, and is the main reference point to see "the current state of things". I don't think it's a stretch to see why the master/slave relationship seems a more fitting sense of "master" than "master copy".
> Git's terminology descends from BitKeeper, which was explicitly using master/slave
That GNOME mailing list post was retracted the next year[0].
I wrote a summary of the history[1] for Git Rev News, the git developers newsletter. In short, the usage didn't come from BitKeeper, and was intended to mean 'master copy'.
After the article was published, Aaron Kushner from BitKeeper reached out and gave me some more history on the usage of 'slave repository' in that one particular spot in BitKeeper[2]: it was a presentation for a client that was already using master/slave terminology and so the same terms were used in the presentation.
Additionally, I don't think sense 29 actually makes sense here. A "master copy" is immutable. Once somebody burns a master record, that's it — you're done. You make copies from that one because it is deemed "correct" in some sense.
But git branches are not immutable; they are able to be added to at any point. The master branch can be interpreted as collating the work done by all of the other branches: non-master branches do some work, then it gets merged back to `master`. Which means... the master branch is coordinating work done in other branches. And, in many git workflows, work on the master branch itself is discouraged, meaning almost all work is done in separate branches and then the master branch is used to accumulate that work, and is the main reference point to see "the current state of things". I don't think it's a stretch to see why the master/slave relationship seems a more fitting sense of "master" than "master copy".