| Message ID | b36e3f99716bf3976fc886df684c300e17566c79.1623085069.git.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Use singular "they" when appropriate | expand |
On Mon, Jun 07 2021, Derrick Stolee via GitGitGadget wrote: > From: Derrick Stolee <dstolee@microsoft.com> > > Several comments in our code refer to an anonymous user with "he/him" or > "she/her" pronouns, and the choice between the two is arbitrary. > > Replace these uses with "they/them" which universally includes all > potential readers. > > Signed-off-by: Derrick Stolee <dstolee@microsoft.com> > --- > commit.c | 2 +- > config.h | 2 +- > contrib/hooks/multimail/git_multimail.py | 4 ++-- We should not change upstream projects we pull in like that, see README.Git in that directory + https://github.com/git-multimail/git-multimail.
On 6/7/2021 1:12 PM, Ævar Arnfjörð Bjarmason wrote: > > On Mon, Jun 07 2021, Derrick Stolee via GitGitGadget wrote: > >> From: Derrick Stolee <dstolee@microsoft.com> >> >> Several comments in our code refer to an anonymous user with "he/him" or >> "she/her" pronouns, and the choice between the two is arbitrary. >> >> Replace these uses with "they/them" which universally includes all >> potential readers. >> >> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> >> --- >> commit.c | 2 +- >> config.h | 2 +- >> contrib/hooks/multimail/git_multimail.py | 4 ++-- > > We should not change upstream projects we pull in like that, see > README.Git in that directory + > https://github.com/git-multimail/git-multimail. Whoops. Thanks. I wasn't looking carefully enough at the path. -Stolee
"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes: > @@ -1178,7 +1178,7 @@ static void handle_signed_tag(struct commit *parent, struct commit_extra_header > /* > * We could verify this signature and either omit the tag when > * it does not validate, but the integrator may not have the > - * public key of the signer of the tag he is merging, while a > + * public key of the signer of the tag they are merging, while a > * later auditor may have it while auditing, so let's not run > * verify-signed-buffer here for now... > * This is not wrong per-se, but "the tag being merged" is something I would have written, as naive non-native English speakers would find it disturbing and ungrammatical that "the integrator" singular is matched with "singular" they, which goes opposite from what they were taught in their foreign language classes [*1*]. Perhaps offer a passive voice as a weaker alternative to the singular they in the guidelines patch? [Footnote] *1* I started writing this paragraph first with a singular subject "a naive non-native speaker", found "his or her foreign language class" problematic, and worked it around by make the statement about plural speakers. That may qualify as the third option.
Junio C Hamano wrote: > "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes: > > > @@ -1178,7 +1178,7 @@ static void handle_signed_tag(struct commit *parent, struct commit_extra_header > > /* > > * We could verify this signature and either omit the tag when > > * it does not validate, but the integrator may not have the > > - * public key of the signer of the tag he is merging, while a > > + * public key of the signer of the tag they are merging, while a > > * later auditor may have it while auditing, so let's not run > > * verify-signed-buffer here for now... > > * > > This is not wrong per-se, but "the tag being merged" is something I > would have written, as naive non-native English speakers would find > it disturbing and ungrammatical that "the integrator" singular is > matched with "singular" they, which goes opposite from what they > were taught in their foreign language classes [*1*]. It's not just non-native English speakers. According to linguists the singular "they" only makes sense when the antecedent is plural (comes from a pool of people), in this case "the integrator" is semantically singular. 58% of the Usage Panel of the American Heritage Dictionary would disagree with this usage [1]. > Perhaps offer a passive voice as a weaker alternative to the > singular they in the guidelines patch? Yes, "of the tag being merged" does read correctly to me, unlike the version above. Cheers. [1] https://ahdictionary.tumblr.com/post/147597257733/updated-usage-note-they
On Mon, Jun 07, 2021 at 04:57:46PM +0000, Derrick Stolee via GitGitGadget wrote: > > > Several comments in our code refer to an anonymous user with "he/him" or > "she/her" pronouns, and the choice between the two is arbitrary. > > Replace these uses with "they/them" which universally includes all > potential readers. Thanks. I'm especially glad to see the codebase start to unify instead of awkwardly choosing between "he", "she", "he or she", or even "(s)he". This seems a lot neater. Reviewed-by: Emily Shaffer <emilyshaffer@google.com>
Hi, On Mon, 7 Jun 2021, Ævar Arnfjörð Bjarmason wrote: > On Mon, Jun 07 2021, Derrick Stolee via GitGitGadget wrote: > > > From: Derrick Stolee <dstolee@microsoft.com> > > > > Several comments in our code refer to an anonymous user with "he/him" or > > "she/her" pronouns, and the choice between the two is arbitrary. > > > > Replace these uses with "they/them" which universally includes all > > potential readers. > > > > Signed-off-by: Derrick Stolee <dstolee@microsoft.com> > > --- > > commit.c | 2 +- > > config.h | 2 +- > > contrib/hooks/multimail/git_multimail.py | 4 ++-- > > We should not change upstream projects we pull in like that, see > README.Git in that directory + > https://github.com/git-multimail/git-multimail. It is probably a good idea to make that upstream project not only the authoritative source, but the only source. In other words, I think we should replace the files in `contrib/hooks/multimail/` by a `README` that points to the indicated URL. Ciao, Dscho
diff --git a/commit.c b/commit.c index 8ea55a447fa9..35e93abce6ae 100644 --- a/commit.c +++ b/commit.c @@ -1178,7 +1178,7 @@ static void handle_signed_tag(struct commit *parent, struct commit_extra_header /* * We could verify this signature and either omit the tag when * it does not validate, but the integrator may not have the - * public key of the signer of the tag he is merging, while a + * public key of the signer of the tag they are merging, while a * later auditor may have it while auditing, so let's not run * verify-signed-buffer here for now... * diff --git a/config.h b/config.h index 9038538ffdcb..7107b41a8933 100644 --- a/config.h +++ b/config.h @@ -451,7 +451,7 @@ void git_configset_init(struct config_set *cs); * Parses the file and adds the variable-value pairs to the `config_set`, * dies if there is an error in parsing the file. Returns 0 on success, or * -1 if the file does not exist or is inaccessible. The user has to decide - * if he wants to free the incomplete configset or continue using it when + * if they want to free the incomplete configset or continue using it when * the function returns -1. */ int git_configset_add_file(struct config_set *cs, const char *filename); diff --git a/contrib/hooks/multimail/git_multimail.py b/contrib/hooks/multimail/git_multimail.py index f563be82fc7e..5932a3354f26 100755 --- a/contrib/hooks/multimail/git_multimail.py +++ b/contrib/hooks/multimail/git_multimail.py @@ -3219,7 +3219,7 @@ class GitoliteEnvironmentLowPrecMixin( def get_repo_shortname(self): # The gitolite environment variable $GL_REPO is a pretty good # repo_shortname (though it's probably not as good as a value - # the user might have explicitly put in his config). + # the user might have explicitly put in their config). return ( self.osenv.get('GL_REPO', None) or super(GitoliteEnvironmentLowPrecMixin, self).get_repo_shortname() @@ -3361,7 +3361,7 @@ def get_pusher(self): # __submitter into an RFC 2822 string already. return re.match(r'(.*?)\s*<', self.__submitter).group(1) else: - # Submitter has no configured email, it's just his name. + # Submitter has no configured email, it's just their name. return self.__submitter else: # If we arrive here, this means someone pushed "Submit" from diff --git a/date.c b/date.c index f9ea807b3a9f..2da0f80b9bfa 100644 --- a/date.c +++ b/date.c @@ -908,7 +908,7 @@ int parse_expiry_date(const char *date, timestamp_t *timestamp) /* * We take over "now" here, which usually translates * to the current timestamp. This is because the user - * really means to expire everything she has done in + * really means to expire everything they have done in * the past, and by definition reflogs are the record * of the past, and there is nothing from the future * to be kept. diff --git a/pathspec.h b/pathspec.h index fceebb876f7a..6e84099bea22 100644 --- a/pathspec.h +++ b/pathspec.h @@ -108,7 +108,7 @@ struct pathspec { * * A similar process is applied when a new pathspec magic is added. The designer * lifts the GUARD_PATHSPEC restriction in the functions that support the new - * magic. At the same time (s)he has to make sure this new feature will be + * magic. At the same time they have to make sure this new feature will be * caught at parse_pathspec() in commands that cannot handle the new magic in * some cases. grepping parse_pathspec() should help. */ diff --git a/strbuf.h b/strbuf.h index 223ee2094af8..b543e354f0ed 100644 --- a/strbuf.h +++ b/strbuf.h @@ -338,7 +338,7 @@ const char *strbuf_join_argv(struct strbuf *buf, int argc, * * In order to facilitate caching and to make it possible to give * parameters to the callback, `strbuf_expand()` passes a context pointer, - * which can be used by the programmer of the callback as she sees fit. + * which can be used by the programmer of the callback as they see fit. */ typedef size_t (*expand_fn_t) (struct strbuf *sb, const char *placeholder, diff --git a/wt-status.c b/wt-status.c index 42b673571696..bd7ef3e4fd02 100644 --- a/wt-status.c +++ b/wt-status.c @@ -639,7 +639,7 @@ static void wt_status_collect_changes_index(struct wt_status *s) * mode by passing a command line option we do not ignore any * changed submodule SHA-1s when comparing index and HEAD, no * matter what is configured. Otherwise the user won't be - * shown any submodules she manually added (and which are + * shown any submodules they manually added (and which are * staged to be committed), which would be really confusing. */ handle_ignore_submodules_arg(&rev.diffopt, "dirty");