git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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.

  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

  List information: http://vger.kernel.org/majordomo-info.html

* 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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).