git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH 2/5] t/test-terminal: avoid non-inclusive language
Date: Wed, 16 Sep 2020 14:05:30 -0700	[thread overview]
Message-ID: <xmqqft7hwhyd.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <3b4ae48d4a3a7e2d6aae259ead19b6643d2533e8.1600279853.git.gitgitgadget@gmail.com> (Johannes Schindelin via GitGitGadget's message of "Wed, 16 Sep 2020 18:10:50 +0000")

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> In the ongoing effort to make the Git project a more inclusive place,
> let's try to avoid names like "master" where possible.

The two sides of a PTY are called 'master' and 'slave', and I
understand there is a push to move away from these words, but
calling one side with an invented name that is used by nobody else
in the context of talking about PTY, while keeping the word used to
call the other side, would lead to confusion.

A better change is to drop "master_" altogether without replacing
the word with anything, and call them just "input", "output" and
"error".  For those who implement the PTY, calling both ends of the
pipe 'master' vs 'slave' may be useful for them, as they are terms
of art they are used to think with.  But as end-users of PTY, the
fact that we are holding the 'master' end, and access to the 'slave'
end is done by asking the 'master' end we hold for the corresponding
'slave', is not that important.  What each of these three PTYs is
used for is much more important.

If $input, $output, and $error are too terse, spell them out as
$term_input, $term_output and $term_error or something like that,
perhaps.

Thanks.

  reply	other threads:[~2020-09-16 21:05 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-16 18:10 [PATCH 0/5] Inclusive naming, part II Johannes Schindelin via GitGitGadget
2020-09-16 18:10 ` [PATCH 1/5] fast-export: avoid using unnecessary language in a code comment Johannes Schindelin via GitGitGadget
2020-09-16 21:05   ` Junio C Hamano
2020-09-16 18:10 ` [PATCH 2/5] t/test-terminal: avoid non-inclusive language Johannes Schindelin via GitGitGadget
2020-09-16 21:05   ` Junio C Hamano [this message]
2020-09-16 21:25     ` Junio C Hamano
2020-09-20 15:34       ` Johannes Schindelin
2020-09-21 21:12         ` Junio C Hamano
2020-09-16 18:10 ` [PATCH 3/5] t3200: avoid variations of the `master` branch name Johannes Schindelin via GitGitGadget
2020-09-16 21:11   ` Jeff King
2020-09-16 22:28     ` Junio C Hamano
2020-09-16 22:39       ` Jeff King
2020-09-20 15:43         ` Johannes Schindelin
2020-09-21 21:26           ` Junio C Hamano
2020-09-16 18:10 ` [PATCH 4/5] tests: " Johannes Schindelin via GitGitGadget
2020-09-16 18:10 ` [PATCH 5/5] t9902: avoid using the branch name `master` Johannes Schindelin via GitGitGadget
2020-09-21 22:01 ` [PATCH v2 0/5] Inclusive naming, part II Johannes Schindelin via GitGitGadget
2020-09-21 22:01   ` [PATCH v2 1/5] fast-export: avoid using unnecessary language in a code comment Johannes Schindelin via GitGitGadget
2020-09-21 22:01   ` [PATCH v2 2/5] t/test-terminal: avoid non-inclusive language Johannes Schindelin via GitGitGadget
2020-09-21 22:01   ` [PATCH v2 3/5] t3200: avoid variations of the `master` branch name Johannes Schindelin via GitGitGadget
2020-09-21 22:01   ` [PATCH v2 4/5] tests: " Johannes Schindelin via GitGitGadget
2020-09-21 22:31     ` Junio C Hamano
2020-09-26  4:20       ` Johannes Schindelin
2020-09-21 22:01   ` [PATCH v2 5/5] t9902: avoid using the branch name `master` Johannes Schindelin via GitGitGadget
2020-09-21 22:35     ` Junio C Hamano
2020-09-26  4:25       ` Johannes Schindelin
2020-09-21 22:24   ` [PATCH v2 0/5] Inclusive naming, part II Jeff King
2020-09-26  4:29     ` Johannes Schindelin
2020-09-27  8:45       ` Jeff King
2020-09-26 21:04   ` [PATCH v3 " Johannes Schindelin via GitGitGadget
2020-09-26 21:04     ` [PATCH v3 1/5] fast-export: avoid using unnecessary language in a code comment Johannes Schindelin via GitGitGadget
2020-09-26 21:04     ` [PATCH v3 2/5] t/test-terminal: avoid non-inclusive language Johannes Schindelin via GitGitGadget
2020-09-26 21:04     ` [PATCH v3 3/5] t3200: avoid variations of the `master` branch name Johannes Schindelin via GitGitGadget
2020-09-26 21:04     ` [PATCH v3 4/5] tests: " Johannes Schindelin via GitGitGadget
2020-09-26 21:04     ` [PATCH v3 5/5] t9902: avoid using the branch name `master` Johannes Schindelin via GitGitGadget
2020-09-30 22:21     ` [PATCH v3 0/5] Inclusive naming, part II Junio C Hamano
2020-09-30 22:34       ` Jeff King
2020-09-30 22:57         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqft7hwhyd.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=johannes.schindelin@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).