[PATCH 0/6] Some small documentation fixes

[PATCH 0/6] Some small documentation fixes

[Ralf Wildenhues]

Hello git list,

Being rather new to git, I've read the manual, and found some
minor issues.  Posting them in the hope that they are useful,
and that you don't mind me splitting them up in small pieces.

Please Cc: me on replies.

Cheers,
Ralf, thanks for a cool tool :-)

[PATCH 1/6] Fix some typos, punctuation, missing words, minor markup.

[Ralf Wildenhues]

---
 Documentation/config.txt          |    4 ++--
 Documentation/git-diff.txt        |    2 +-
 Documentation/git-index-pack.txt  |    2 +-
 Documentation/git-merge-index.txt |    2 +-
 Documentation/git-stash.txt       |    2 +-
 Documentation/git-svn.txt         |    2 +-
 Documentation/git-tag.txt         |    2 +-
 Documentation/git.txt             |    4 ++--
 Documentation/glossary.txt        |    6 +++---
 Documentation/user-manual.txt     |   27 ++++++++++++++-------------
 10 files changed, 27 insertions(+), 26 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 015910f..6afc1dc 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -188,7 +188,7 @@ core.worktree::
 	Set the path to the working tree.  The value will not be
 	used in combination with repositories found automatically in
 	a .git directory (i.e. $GIT_DIR is not set).
-	This can be overriden by the GIT_WORK_TREE environment
+	This can be overridden by the GIT_WORK_TREE environment
 	variable and the '--work-tree' command line option.
 
 core.logAllRefUpdates::
@@ -588,7 +588,7 @@ merge.verbosity::
 	message if conflicts were detected. Level 1 outputs only
 	conflicts, 2 outputs conflicts and file changes.  Level 5 and
 	above outputs debugging information.  The default is level 2.
-	Can be overriden by 'GIT_MERGE_VERBOSITY' environment variable.
+	Can be overridden by 'GIT_MERGE_VERBOSITY' environment variable.
 
 merge.<driver>.name::
 	Defines a human readable name for a custom low-level
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index db2eb46..ce0f502 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -125,7 +125,7 @@ $ git diff topic...master  <3>
 +
 <1> Changes between the tips of the topic and the master branches.
 <2> Same as above.
-<3> Changes that occured on the master branch since when the topic
+<3> Changes that occurred on the master branch since when the topic
 branch was started off it.
 
 Limiting the diff output::
diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt
index a8a7f6f..bf5c2bd 100644
--- a/Documentation/git-index-pack.txt
+++ b/Documentation/git-index-pack.txt
@@ -43,7 +43,7 @@ OPTIONS
 	a default name determined from the pack content.  If
 	<pack-file> is not specified consider using --keep to
 	prevent a race condition between this process and
-	gitlink::git-repack[1] .
+	gitlink::git-repack[1].
 
 --fix-thin::
 	It is possible for gitlink:git-pack-objects[1] to build
diff --git a/Documentation/git-merge-index.txt b/Documentation/git-merge-index.txt
index 17e9f10..b726ddf 100644
--- a/Documentation/git-merge-index.txt
+++ b/Documentation/git-merge-index.txt
@@ -40,7 +40,7 @@ If "git-merge-index" is called with multiple <file>s (or -a) then it
 processes them in turn only stopping if merge returns a non-zero exit
 code.
 
-Typically this is run with the a script calling git's imitation of
+Typically this is run with a script calling git's imitation of
 the merge command from the RCS package.
 
 A sample script called "git-merge-one-file" is included in the
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 5723bb0..c0147b9 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -57,7 +57,7 @@ stash@{1}: On master: 9cc0589... Add git-stash
 
 show [<stash>]::
 
-	Show the changes recorded in the stash as a diff between the the
+	Show the changes recorded in the stash as a diff between the
 	stashed state and its original parent. When no `<stash>` is given,
 	shows the latest one. By default, the command shows the diffstat, but
 	it will accept any format known to `git-diff` (e.g., `git-stash show
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index e157c6a..488e4b1 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -404,7 +404,7 @@ section because they affect the 'git-svn-id:' metadata line.
 BASIC EXAMPLES
 --------------
 
-Tracking and contributing to a the trunk of a Subversion-managed project:
+Tracking and contributing to the trunk of a Subversion-managed project:
 
 ------------------------------------------------------------------------
 # Clone a repo (like git clone):
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 990ae4f..22a23bf 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -112,7 +112,7 @@ You really want to call the new version "X" too, 'even though'
 others have already seen the old one. So just use "git tag -f"
 again, as if you hadn't already published the old one.
 
-However, Git does *not* (and it should not)change tags behind
+However, Git does *not* (and it should not) change tags behind
 users back. So if somebody already got the old tag, doing a "git
 pull" on your tree shouldn't just make them overwrite the old
 one.
diff --git a/Documentation/git.txt b/Documentation/git.txt
index abce801..bba8d54 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -325,7 +325,7 @@ For a more complete list of ways to spell object names, see
 File/Directory Structure
 ------------------------
 
-Please see link:repository-layout.html[repository layout] document.
+Please see the link:repository-layout.html[repository layout] document.
 
 Read link:hooks.html[hooks] for more details about each hook.
 
@@ -335,7 +335,7 @@ Higher level SCMs may provide and manage additional information in the
 
 Terminology
 -----------
-Please see link:glossary.html[glossary] document.
+Please see the link:glossary.html[glossary] document.
 
 
 Environment Variables
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index 3f7b1e4..d99fa19 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -52,8 +52,8 @@ GIT Glossary
 [[def_cherry-picking]]cherry-picking::
 	In <<def_SCM,SCM>> jargon, "cherry pick" means to choose a subset of
 	changes out of a series of changes (typically commits) and record them
-	as a new series of changes on top of different codebase. In GIT, this is
-	performed by "git cherry-pick" command to extract the change introduced
+	as a new series of changes on top of a different codebase. In GIT, this is
+	performed by the "git cherry-pick" command to extract the change introduced
 	by an existing <<def_commit,commit>> and to record it based on the tip
 	of the current <<def_branch,branch>> as a new commit.
 
@@ -347,7 +347,7 @@ This commit is referred to as a "merge commit", or sometimes just a
 	it as my origin branch head". And `git push
 	$URL refs/heads/master:refs/heads/to-upstream` means "publish my
 	master branch head as to-upstream branch at $URL". See also
-	gitlink:git-push[1]
+	gitlink:git-push[1].
 
 [[def_repository]]repository::
 	A collection of <<def_ref,refs>> together with an
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index c7fdf25..6adeca7 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1495,7 +1495,7 @@ Ensuring good performance
 -------------------------
 
 On large repositories, git depends on compression to keep the history
-information from taking up to much space on disk or in memory.
+information from taking up too much space on disk or in memory.
 
 This compression is not performed automatically.  Therefore you
 should occasionally run gitlink:git-gc[1]:
@@ -1920,7 +1920,7 @@ As with git-fetch, git-push will complain if this does not result in
 a <<fast-forwards,fast forward>>.  Normally this is a sign of
 something wrong.  However, if you are sure you know what you're
 doing, you may force git-push to perform the update anyway by
-proceeding the branch name by a plus sign:
+preceding the branch name by a plus sign:
 
 -------------------------------------------------
 $ git push ssh://yourserver.com/~you/proj.git +master
@@ -2040,7 +2040,7 @@ $ git branch --track test origin/master
 $ git branch --track release origin/master
 -------------------------------------------------
 
-These can be easily kept up to date using gitlink:git-pull[1]
+These can be easily kept up to date using gitlink:git-pull[1].
 
 -------------------------------------------------
 $ git checkout test && git pull
@@ -2132,7 +2132,7 @@ changes are in a specific branch, use:
 $ git log linux..branchname | git-shortlog
 -------------------------------------------------
 
-To see whether it has already been merged into the test or release branches
+To see whether it has already been merged into the test or release branches,
 use:
 
 -------------------------------------------------
@@ -2145,12 +2145,12 @@ or
 $ git log release..branchname
 -------------------------------------------------
 
-(If this branch has not yet been merged you will see some log entries.
+(If this branch has not yet been merged, you will see some log entries.
 If it has been merged, then there will be no output.)
 
 Once a patch completes the great cycle (moving from test to release,
 then pulled by Linus, and finally coming back into your local
-"origin/master" branch) the branch for this change is no longer needed.
+"origin/master" branch), the branch for this change is no longer needed.
 You detect this when the output from:
 
 -------------------------------------------------
@@ -2479,7 +2479,7 @@ $ git checkout -b mywork-new origin
 $ gitk origin..mywork &
 -------------------------------------------------
 
-And browse through the list of patches in the mywork branch using gitk,
+and browse through the list of patches in the mywork branch using gitk,
 applying them (possibly in a different order) to mywork-new using
 cherry-pick, and possibly modifying them as you go using commit --amend.
 The gitlink:git-gui[1] command may also help as it allows you to
@@ -2739,7 +2739,7 @@ others:
 
 - Git can quickly determine whether two objects are identical or not,
   just by comparing names.
-- Since object names are computed the same way in ever repository, the
+- Since object names are computed the same way in every repository, the
   same content stored in two repositories will always be stored under
   the same name.
 - Git can detect errors when it reads an object, by checking that the
@@ -3425,9 +3425,10 @@ The Workflow
 ------------
 
 High-level operations such as gitlink:git-commit[1],
-gitlink:git-checkout[1] and git-reset[1] work by moving data between the
-working tree, the index, and the object database.  Git provides
-low-level operations which perform each of these steps individually.
+gitlink:git-checkout[1] and gitlink:git-reset[1] work by moving data
+between the working tree, the index, and the object database.  Git
+provides low-level operations which perform each of these steps
+individually.
 
 Generally, all "git" operations work on the index file. Some operations
 work *purely* on the index file (showing the current state of the
@@ -3704,7 +3705,7 @@ Merging multiple trees, continued
 ---------------------------------
 
 Sadly, many merges aren't trivial. If there are files that have
-been added.moved or removed, or if both branches have modified the
+been added, moved or removed, or if both branches have modified the
 same file, you will be left with an index tree that contains "merge
 entries" in it. Such an index tree can 'NOT' be written out to a tree
 object, and you will have to resolve any such merge clashes using
@@ -4061,7 +4062,7 @@ $ git branch new     # create branch "new" starting at current HEAD
 $ git branch -d new  # delete branch "new"
 -----------------------------------------------
 
-Instead of basing new branch on current HEAD (the default), use:
+Instead of basing a new branch on current HEAD (the default), use:
 
 -----------------------------------------------
 $ git branch new test    # branch named "test"
-- 
1.5.3.3.g34c6d

[PATCH 2/6] Fix wording in push definition.

[Ralf Wildenhues]

Make the definition of push in the glossary readable.
---
 Documentation/glossary.txt |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index d99fa19..5645177 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -301,8 +301,8 @@ This commit is referred to as a "merge commit", or sometimes just a
 [[def_push]]push::
 	Pushing a <<def_branch,branch>> means to get the branch's
 	<<def_head_ref,head ref>> from a remote <<def_repository,repository>>,
-	find out if it is an ancestor to the branch's local
-	head ref is a direct, and in that case, putting all
+	find out if it is a direct ancestor to the branch's local
+	head ref, and in that case, putting all
 	objects, which are <<def_reachable,reachable>> from the local
 	head ref, and which are missing from the remote
 	repository, into the remote
-- 
1.5.3.3.g34c6d

[PATCH 3/6] manual: Fix example finding commits referencing given content.

[Ralf Wildenhues]

If I'm handed a file, then it typically lives outside the
working directory.  git-log only operates on in-tree files,
so the first 'filename' should be an in-tree one, or it should
look at all files.  This patch does the latter, so it would
also find renamed files.  However, it is also slower.
---
 Documentation/user-manual.txt |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 6adeca7..2b1b324 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -926,7 +926,7 @@ file such that it contained the given content either before or after the
 commit.  You can find out with this:
 
 -------------------------------------------------
-$  git log --raw --abbrev=40 --pretty=oneline -- filename |
+$  git log --raw --abbrev=40 --pretty=oneline |
 	grep -B 1 `git hash-object filename`
 -------------------------------------------------
 
-- 
1.5.3.3.g34c6d

[PATCH 4/6] manual: add some markup.

[Ralf Wildenhues]

---
 Documentation/glossary.txt    |    2 +-
 Documentation/user-manual.txt |   10 +++++-----
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index 5645177..fc18744 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -281,7 +281,7 @@ This commit is referred to as a "merge commit", or sometimes just a
 [[def_pickaxe]]pickaxe::
 	The term <<def_pickaxe,pickaxe>> refers to an option to the diffcore
 	routines that help select changes that add or delete a given text
-	string. With the --pickaxe-all option, it can be used to view the full
+	string. With the `--pickaxe-all` option, it can be used to view the full
 	<<def_changeset,changeset>> that introduced or removed, say, a
 	particular line of text. See gitlink:git-diff[1].
 
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 2b1b324..df482e6 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1536,7 +1536,7 @@ dangling tree b24c2473f1fd3d91352a624795be026d64c8841f
 Dangling objects are not a problem.  At worst they may take up a little
 extra disk space.  They can sometimes provide a last-resort method for
 recovering lost work--see <<dangling-objects>> for details.  However, if
-you wish, you can remove them with gitlink:git-prune[1] or the --prune
+you wish, you can remove them with gitlink:git-prune[1] or the `--prune`
 option to gitlink:git-gc[1]:
 
 -------------------------------------------------
@@ -1555,7 +1555,7 @@ Recovering lost changes
 Reflogs
 ^^^^^^^
 
-Say you modify a branch with gitlink:git-reset[1] --hard, and then
+Say you modify a branch with `gitlink:git-reset[1] --hard`, and then
 realize that the branch was the only reference you had to that point in
 history.
 
@@ -1684,7 +1684,7 @@ $ git pull
 More generally, a branch that is created from a remote branch will pull
 by default from that branch.  See the descriptions of the
 branch.<name>.remote and branch.<name>.merge options in
-gitlink:git-config[1], and the discussion of the --track option in
+gitlink:git-config[1], and the discussion of the `--track` option in
 gitlink:git-checkout[1], to learn how to control these defaults.
 
 In addition to saving you keystrokes, "git pull" also helps you by
@@ -2412,7 +2412,7 @@ $ git rebase --continue
 
 and git will continue applying the rest of the patches.
 
-At any point you may use the --abort option to abort this process and
+At any point you may use the `--abort` option to abort this process and
 return mywork to the state it had before you started the rebase:
 
 -------------------------------------------------
@@ -2481,7 +2481,7 @@ $ gitk origin..mywork &
 
 and browse through the list of patches in the mywork branch using gitk,
 applying them (possibly in a different order) to mywork-new using
-cherry-pick, and possibly modifying them as you go using commit --amend.
+cherry-pick, and possibly modifying them as you go using `commit --amend`.
 The gitlink:git-gui[1] command may also help as it allows you to
 individually select diff hunks for inclusion in the index (by
 right-clicking on the diff hunk and choosing "Stage Hunk for Commit").
-- 
1.5.3.3.g34c6d

[PATCH 5/6] manual: use 'URL' instead of 'url'.

[Ralf Wildenhues]

Just for consistency, use the spelling URL everywhere.
---
 Documentation/user-manual.txt |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index df482e6..38e35d8 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1782,7 +1782,7 @@ $ git clone /path/to/repository
 $ git pull /path/to/other/repository
 -------------------------------------------------
 
-or an ssh url:
+or an ssh URL:
 
 -------------------------------------------------
 $ git clone ssh://yourhost/~you/repository
@@ -1843,7 +1843,7 @@ Exporting a git repository via the git protocol
 This is the preferred method.
 
 If someone else administers the server, they should tell you what
-directory to put the repository in, and what git:// url it will appear
+directory to put the repository in, and what git:// URL it will appear
 at.  You can then skip to the section
 "<<pushing-changes-to-a-public-repository,Pushing changes to a public
 repository>>", below.
@@ -1880,8 +1880,8 @@ $ chmod a+x hooks/post-update
 gitlink:git-update-server-info[1], and the documentation
 link:hooks.html[Hooks used by git].)
 
-Advertise the url of proj.git.  Anybody else should then be able to
-clone or pull from that url, for example with a command line like:
+Advertise the URL of proj.git.  Anybody else should then be able to
+clone or pull from that URL, for example with a command line like:
 
 -------------------------------------------------
 $ git clone http://yourserver.com/~you/proj.git
-- 
1.5.3.3.g34c6d

[PATCH 0/6] manual: Fix or remove em dashes.

[Ralf Wildenhues]

em dashes were used inconsistently in the manual.
This changes them to the way they are used in US English.
---
 Documentation/user-manual.txt |   20 ++++++++++----------
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 38e35d8..d99adc6 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2756,7 +2756,7 @@ There are four different types of objects: "blob", "tree", "commit", and
   "blob" objects into a directory structure. In addition, a tree object
   can refer to other tree objects, thus creating a directory hierarchy.
 - A <<def_commit_object,"commit" object>> ties such directory hierarchies
-  together into a <<def_DAG,directed acyclic graph>> of revisions - each
+  together into a <<def_DAG,directed acyclic graph>> of revisions--each
   commit contains the object name of exactly one tree designating the
   directory hierarchy at the time of the commit. In addition, a commit
   refers to "parent" commit objects that describe the history of how we
@@ -3029,7 +3029,7 @@ There are also other situations that cause dangling objects. For
 example, a "dangling blob" may arise because you did a "git add" of a
 file, but then, before you actually committed it and made it part of the
 bigger picture, you changed something else in that file and committed
-that *updated* thing - the old state that you added originally ends up
+that *updated* thing--the old state that you added originally ends up
 not being pointed to by any commit or tree, so it's now a dangling blob
 object.
 
@@ -3044,7 +3044,7 @@ up pointing to them, so they end up "dangling" in your repository.
 Generally, dangling objects aren't anything to worry about. They can
 even be very useful: if you screw something up, the dangling objects can
 be how you recover your old tree (say, you did a rebase, and realized
-that you really didn't want to - you can look at what dangling objects
+that you really didn't want to--you can look at what dangling objects
 you have, and decide to reset your head to some old dangling state).
 
 For commits, you can just use:
@@ -3088,10 +3088,10 @@ $ git prune
 ------------------------------------------------
 
 and they'll be gone. But you should only run "git prune" on a quiescent
-repository - it's kind of like doing a filesystem fsck recovery: you
+repository--it's kind of like doing a filesystem fsck recovery: you
 don't want to do that while the filesystem is mounted.
 
-(The same is true of "git-fsck" itself, btw - but since
+(The same is true of "git-fsck" itself, btw, but since
 git-fsck never actually *changes* the repository, it just reports
 on what it found, git-fsck itself is never "dangerous" to run.
 Running it while somebody is actually changing the repository can cause
@@ -3483,7 +3483,7 @@ You write your current index file to a "tree" object with the program
 $ git write-tree
 -------------------------------------------------
 
-that doesn't come with any options - it will just write out the
+that doesn't come with any options--it will just write out the
 current index into the set of tree objects that describe that state,
 and it will return the name of the resulting top-level tree. You can
 use that tree to re-generate the index at any time by going in the
@@ -3494,7 +3494,7 @@ object database -> index
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
 You read a "tree" file from the object database, and use that to
-populate (and overwrite - don't do this if your index contains any
+populate (and overwrite--don't do this if your index contains any
 unsaved state that you might want to restore later!) your current
 index.  Normal operation is just
 
@@ -3542,7 +3542,7 @@ Tying it all together
 
 To commit a tree you have instantiated with "git-write-tree", you'd
 create a "commit" object that refers to that tree and the history
-behind it - most notably the "parent" commits that preceded it in
+behind it--most notably the "parent" commits that preceded it in
 history.
 
 Normally a "commit" has one parent: the previous state of the tree
@@ -3685,7 +3685,7 @@ Once you know the three trees you are going to merge (the one "original"
 tree, aka the common tree, and the two "result" trees, aka the branches
 you want to merge), you do a "merge" read into the index. This will
 complain if it has to throw away your old index contents, so you should
-make sure that you've committed those - in fact you would normally
+make sure that you've committed those--in fact you would normally
 always do a merge against your last commit (which should thus match what
 you have in your current index anyway).
 
@@ -3957,7 +3957,7 @@ Two things are interesting here:
 
 - `get_sha1()` returns 0 on _success_.  This might surprise some new
   Git hackers, but there is a long tradition in UNIX to return different
-  negative numbers in case of different errors -- and 0 on success.
+  negative numbers in case of different errors--and 0 on success.
 
 - the variable `sha1` in the function signature of `get_sha1()` is `unsigned
   char \*`, but is actually expected to be a pointer to `unsigned
-- 
1.5.3.3.g34c6d

Re: [PATCH 0/6] manual: Fix or remove em dashes.

[Thomas Adam]

Hello --

On 09/10/2007, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> em dashes were used inconsistently in the manual.
> This changes them to the way they are used in US English.

I find this particular patch to be rather odd; there is nothing
invalid in the way the em-dashes are used.  Why is it US English is
somehow de facto over, say, proper English?  :)

-- Thomas Adam

Re: [PATCH 0/6] manual: Fix or remove em dashes.

[Ralf Wildenhues]

Hello, and sorry, this patch should be number 6/6 of course.

* Thomas Adam wrote on Tue, Oct 09, 2007 at 11:41:41PM CEST:
> On 09/10/2007, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> > em dashes were used inconsistently in the manual.
> > This changes them to the way they are used in US English.
> 
> I find this particular patch to be rather odd; there is nothing
> invalid in the way the em-dashes are used.

No, not invalid, just inconsistent usage in the manual.

> Why is it US English is somehow de facto over, say, proper English?
> :)

Oh, that was written quoting from memory and experience.  But here's a
quote to back it up, from <http://en.wikipedia.org/wiki/Dash> as of now:

| According to most American sources (e.g., The Chicago Manual of Style)
| and to some British sources (e.g., The Oxford Guide to Style), an em
| dash should always be set closed (not surrounded by spaces). But the
| practice in many parts of the English-speaking world[...] sets it
| open [...]

No, I did not write that!  ;-)

Cheers,
Ralf

Re: [PATCH 0/6] manual: Fix or remove em dashes.

[Thomas Adam]

On 09/10/2007, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> Hello, and sorry, this patch should be number 6/6 of course.
>
> * Thomas Adam wrote on Tue, Oct 09, 2007 at 11:41:41PM CEST:
> > On 09/10/2007, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> > > em dashes were used inconsistently in the manual.
> > > This changes them to the way they are used in US English.
> >
> > I find this particular patch to be rather odd; there is nothing
> > invalid in the way the em-dashes are used.
>
> No, not invalid, just inconsistent usage in the manual.
>
> > Why is it US English is somehow de facto over, say, proper English?
> > :)
>
> Oh, that was written quoting from memory and experience.  But here's a
> quote to back it up, from <http://en.wikipedia.org/wiki/Dash> as of now:
>
> | According to most American sources (e.g., The Chicago Manual of Style)
> | and to some British sources (e.g., The Oxford Guide to Style), an em
> | dash should always be set closed (not surrounded by spaces). But the
> | practice in many parts of the English-speaking world[...] sets it
> | open [...]
>
> No, I did not write that!  ;-)

Well, I don't see why it needs to change, to be honest.  I use
em-dashes all the time surrounded by spaces, as do many academics.
The fact that may here in the UK do not use the letter z in place of s
to satisfy the OSD is also of equal testament to this.

-- Thomas Adam