2 ms·

It's extremely disappointing to see that the primary reaction on HN to this terminology chain is to bemoan the minor inconvenience of having to type fewer lette

It's extremely disappointing to see that the primary reaction on HN to this terminology chain is to bemoan the minor inconvenience of having to type fewer letters or run a replace-all on your scripts. Oh god, the horror. It's almost like people on HN have never used a text replacement tool before. A "master recording" is the immutable "official recording" and is the source from which all copies are made, but the "master" in this term comes from the historical use of a "mastering lathe" to create vinyl records. It's quite clear that a "master branch" in git is not like a master recording, because a master branch isn't immutable and moreover is the branch that changes get merged into. Given that the "master" in historic VCS programs (like Bitkeeper) is explicitly based on master/slave terminology, that git deliberately picked the term to maintain continuity of context with other VCS systems, and that "master" is ultimately a inaccurate description of what a "master branch" actually is in the context of git, it absolutely should be changed to something less inflammatory, like "main" or "working" or "local."

Cogito 6y ago
> Given that the "master" in historic VCS programs (like Bitkeeper) is explicitly based on master/slave terminology, that git deliberately picked the term to maintain continuity of context with other VCS systems... While some VCS programs may have used master/slave (I think maybe CVS did?), BitKeeper did not. The (likely) basis for the belief that BitKeeper use master/slave and git followed them, the GNOME mailing list post[0] that reignited this discussion in 2019, was retracted the next year[1]. I wrote a summary of the history[2] 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[3]: it was a presentation for a client that was already using master/slave terminology and so the same terms were used in the presentation. 0: https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html https://mail.gnome.org/archives/desktop-devel-list/2019-May/... 1: https://mail.gnome.org/archives/desktop-devel-list/2020-June/msg00023.html https://mail.gnome.org/archives/desktop-devel-list/2020-June... 2: https://git.github.io/rev_news/2020/07/29/edition-65/ https://git.github.io/rev_news/2020/07/29/edition-65/ 3: https://twitter.com/AndrewArdill/status/1350537333292949505 https://twitter.com/AndrewArdill/status/1350537333292949505

Cogito 6y ago

> Given that the "master" in historic VCS programs (like Bitkeeper) is explicitly based on master/slave terminology, that git deliberately picked the term to maintain continuity of context with other VCS systems... While some VCS programs may have used master/slave (I think maybe CVS did?), BitKeeper did not. The (likely) basis for the belief that BitKeeper use master/slave and git followed them, the GNOME mailing list post[0] that reignited this discussion in 2019, was retracted the next year[1]. I wrote a summary of the history[2] 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[3]: it was a presentation for a client that was already using master/slave terminology and so the same terms were used in the presentation. 0: https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html https://mail.gnome.org/archives/desktop-devel-list/2019-May/... 1: https://mail.gnome.org/archives/desktop-devel-list/2020-June/msg00023.html https://mail.gnome.org/archives/desktop-devel-list/2020-June... 2: https://git.github.io/rev_news/2020/07/29/edition-65/ https://git.github.io/rev_news/2020/07/29/edition-65/ 3: https://twitter.com/AndrewArdill/status/1350537333292949505 https://twitter.com/AndrewArdill/status/1350537333292949505