On Mon, Jun 22, 2020 at 10:13:31PM +0100, Colin Watson wrote:
> On Mon, Jun 22, 2020 at 05:50:02PM +0200, Michael Biebl wrote:
> > there has been a lot of talk recently about how master is a loaded term
> > that should be avoided.
> > If I read the news correctly, github and others are going to change the
> > default master branch to main.
> > I don't really have any strong opinion on that matter myself.
>
> For a while I'd thought that it was relatively harmless in comparison to
> full-blown uses of master/slave metaphors, but I saw some analysis of
> the history recently that pointed out that git got it from BitKeeper
> which did in fact use a master/slave metaphor [1].
>
Calling that email an analysis is rather charitable. It is really just
a bunch of nonsense. In fact, it is rather impossible to say with any
degree of certainty what thought (or lack thereof) went into the choice
by Linus adopt the "master" terminology in Git. That makes the whole
discussion rather pointless, or a distraction. Rather than focusing on
"why", would it not be better to just take the opportunity to make an
improvement?
> > That said, what I care about is consistency and predictability across
> > the archive.
> > If we deem that "main" is a better term, should we change the defaults
> > in salsa/gitlab and maybe update DEP-14?
>
> I think my ranked preferences are:
>
> 1. devel (for the sorts of reasons smcv@ gave; also, debian/devel is a
> nice allusion to this list)
> 2. trunk (historical familiarity from other VCSes)
> 3. main or maybe mainline (some tab-completion similarity to master,
> though the confusion with components in a Debian context is
> unfortunate)
> 4. further discussion / something else / etc.
> 5. stick with master
>
If we are going to make a change then the motivation should be technical
in nature, which should inform the choice and which should cause us to
ensure that any change made is an improvement. Regardless of whether
the term "master" is harmless, causing imagined harm, or causing real
harm, at present there is a rather fortunate opportunity to make an
objective usability improvement in what has perhaps become the most
common and universal tool used by software developres the world over.
Thinking about the way in which Git is used (regardless of chosen
workflow, paradigm, etc.) names likes "main" and "default" are just as
unclear as "master" in terms of conveying a purpose for the branch.
Sort of like the old dialogs ("Save & exit? Yes/No" and "Discard & exit?
yes/No") that essentially forced you to think about the meaning of each
available choice. Nowadays we use button labels like "Save/Discard"
instead of "Yes/No" because it just works better by reducing the
cognitive burden on the user and making it more likely that the result
of the action will match the user's expectation.
The prevalence of tools that previously used "trunk" makes that not a
terrible choice. However, there are clearly better options.
That said, being that Git as a tool is designed and targeted for
software developers to work on source code (an activity universally
called "development"), renaming "master" to "devel" would mark a
usability improvement. In particular, for any given project I don't
have to figure out, "is 'master' the branch where active development
takes place or does development take place elsewhere and 'master' is the
branch from which releases are made?" A branch called "devel" would
unquestionably be where active development is taking place.
Other branch names could then be chosen based on the needs of the
project, like "test", "stage", & "prod", or "rc" & "release", or
whatever.
Regards,
-Roberto
--
Roberto C. Sánchez
