From: Marc Branchaud <marcnarc@xiplink.com>
To: "Øystein Walle" <oystwa@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Documentation: fix typos in man pages
Date: Tue, 30 Jul 2013 10:51:38 -0400 [thread overview]
Message-ID: <51F7D2FA.7020208@xiplink.com> (raw)
In-Reply-To: <1375132543-20361-1-git-send-email-oystwa@gmail.com>
On 13-07-29 05:15 PM, Øystein Walle wrote:
> Signed-off-by: Øystein Walle <oystwa@gmail.com>
> ---
> I thought I'd take part in the typo fixing frenzy :)
>
> I have some other potential typos lines up. Right now the docs refer to both
> 'filesystem' and 'file system', as well as both 'testsuite' and 'test suite'. I
> think words like these are generally split in English but I'm not sure.
I generally prefer to see the spaces in these words, otherwise it starts to
look more like German.
But of course English is full of exceptions...
> There are also some words that I think look better with with a dash, e.g.
> 'trade-off'. Should I just send these as a patch too instead of jabbering on
> about it?
I'm indifferent to that. I guess it depends on the context, so seeing the
patch would help.
I personally don't have a lot of time to investigate the nuances of English.
However, I desperately hope this list can avoid any linguistic flame wars.
In that spirit, I suggest that anyone posting an orthographic patch (i.e. for
something that isn't an obvious spelling mistake) could helpfully include a
link or two to an explanation of the reasoning for the change. Especially
for folks who aren't native English speakers, this could help avoid a lot of
back-and-forth.
One general source I've found is the English StackExchange:
http://english.stackexchange.com/
> Documentation/git-check-ignore.txt | 2 +-
> Documentation/git-clone.txt | 2 +-
> Documentation/git-daemon.txt | 2 +-
> Documentation/git-diff.txt | 2 +-
> Documentation/gitcli.txt | 2 +-
> Documentation/githooks.txt | 2 +-
> Documentation/gitweb.conf.txt | 4 ++--
> Documentation/user-manual.txt | 2 +-
> 8 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/git-check-ignore.txt b/Documentation/git-check-ignore.txt
> index d2df487..5354301 100644
> --- a/Documentation/git-check-ignore.txt
> +++ b/Documentation/git-check-ignore.txt
> @@ -35,7 +35,7 @@ OPTIONS
> Read file names from stdin instead of from the command-line.
>
> -z::
> - The output format is modified to be machine-parseable (see
> + The output format is modified to be machine-parsable (see
I believe this is a US/UK nuance. As I've recently stated, I think this kind
of change isn't all that helpful as we're likely to see some well-intentioned
person switch it back sometime in the future. If the git project could
choose an official English dialect it would go a long way towards mitigating
such churn.
> below). If `--stdin` is also given, input paths are separated
> with a NUL character instead of a linefeed character.
>
> diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
> index 450f158..3865658 100644
> --- a/Documentation/git-clone.txt
> +++ b/Documentation/git-clone.txt
> @@ -213,7 +213,7 @@ objects from the source repository into a pack in the cloned repository.
> --separate-git-dir=<git dir>::
> Instead of placing the cloned repository where it is supposed
> to be, place the cloned repository at the specified directory,
> - then make a filesytem-agnostic Git symbolic link to there.
> + then make a filesystem-agnostic Git symbolic link to there.
> The result is Git repository can be separated from working
> tree.
>
> diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
> index 223f731..a3283e1 100644
> --- a/Documentation/git-daemon.txt
> +++ b/Documentation/git-daemon.txt
> @@ -189,7 +189,7 @@ Git configuration files in that directory are readable by `<user>`.
> service by exiting with a non-zero status (or to allow it by
> exiting with a zero status). It can also look at the $REMOTE_ADDR
> and $REMOTE_PORT environment variables to learn about the
> - requestor when making this decision.
> + requester when making this decision.
Although I prefer the -or form for this word, this really is one of English's
vague areas. Some words that end with -st definitely take the -er suffix
(tester, jester) but others take the -or suffix (investor). A bit of
Googling also gave no firm result[1][2].
So I think this change is neither good nor bad. However, like the
UK/US-isms, I wonder if there's some way to avoid people changing this back
and forth. But I don't think simply choosing a dialect will help here.
[1]
http://english.stackexchange.com/questions/29254/whats-the-difference-between-requester-and-requestor
[2] http://www.spelling.hemscott.net/ends4.html
> +
> The external command can optionally write a single line to its
> standard output to be sent to the requestor as an error message when
> diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
> index 78d6d50..fe42bf6 100644
> --- a/Documentation/git-diff.txt
> +++ b/Documentation/git-diff.txt
> @@ -39,7 +39,7 @@ directories. This behavior can be forced by --no-index.
> commit relative to the named <commit>. Typically you
> would want comparison with the latest commit, so if you
> do not give <commit>, it defaults to HEAD.
> - If HEAD does not exist (e.g. unborned branches) and
> + If HEAD does not exist (e.g. unborn branches) and
> <commit> is not given, it shows all staged changes.
> --staged is a synonym of --cached.
>
> diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt
> index 9ac5088..670c285 100644
> --- a/Documentation/gitcli.txt
> +++ b/Documentation/gitcli.txt
> @@ -28,7 +28,7 @@ arguments. Here are the rules:
> they can be disambiguated by placing `--` between them.
> E.g. `git diff -- HEAD` is, "I have a file called HEAD in my work
> tree. Please show changes between the version I staged in the index
> - and what I have in the work tree for that file". not "show difference
> + and what I have in the work tree for that file", not "show difference
Good eyes!
M.
next prev parent reply other threads:[~2013-07-30 14:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-29 21:15 [PATCH] Documentation: fix typos in man pages Øystein Walle
2013-07-30 14:51 ` Marc Branchaud [this message]
2013-07-30 15:05 ` Junio C Hamano
2013-07-30 15:11 ` [PATCH] Specify UK English for the documentation source files Marc Branchaud
2013-07-30 15:52 ` Fredrik Gustafsson
2013-07-30 16:40 ` Junio C Hamano
2013-08-01 15:10 ` [PATCH v2] Provide some linguistic guidance for the documentation Marc Branchaud
2013-08-01 15:14 ` Marc Branchaud
2013-08-01 18:21 ` Junio C Hamano
2013-08-01 18:49 ` [PATCH v3] " Marc Branchaud
2013-08-02 6:25 ` [PATCH v2] " Jonathan Nieder
2013-08-02 14:16 ` Marc Branchaud
-- strict thread matches above, loose matches on Subject: below --
2014-02-05 22:19 [PATCH] Documentation: fix typos in man pages Øystein Walle
2014-02-05 22:35 ` 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=51F7D2FA.7020208@xiplink.com \
--to=marcnarc@xiplink.com \
--cc=git@vger.kernel.org \
--cc=oystwa@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.