Documentation: fix misuses of "nor"
Signed-off-by: Justin Lebar <jlebar@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Justin Lebar committed
Mar 31, 2014 at 15:11 UTC
a58088abe2011b6f486de8acd54432f6d9bcecfc
25 files changed
+43
-44
Documentation/CodingGuidelines
+2
-2
@@ -91,13 +91,13 @@ For shell scripts specifically (not exhaustive):
91
E.g.: my_function () {
92
93
- As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
94
- [::], [==], nor [..]) for portability.
94
+ [::], [==], or [..]) for portability.
95
96
- We do not use \{m,n\};
97
98
- We do not use -E;
99
100
- - We do not use ? nor + (which are \{0,1\} and \{1,\}
100
+ - We do not use ? or + (which are \{0,1\} and \{1,\}
101
respectively in BRE) but that goes without saying as these
102
are ERE elements not BRE (note that \? and \+ are not even part
103
of BRE -- making them accessible from BRE is a GNU extension).
Documentation/config.txt
+3
-3
@@ -78,8 +78,8 @@ be escaped: use `\"` for `"` and `\\` for `\`.
78
79
The following escape sequences (beside `\"` and `\\`) are recognized:
80
`\n` for newline character (NL), `\t` for horizontal tabulation (HT, TAB)
81
-and `\b` for backspace (BS). No other char escape sequence, nor octal
82
-char sequences are valid.
81
+and `\b` for backspace (BS). Other char escape sequences (including octal
82
+escape sequences) are invalid.
83
84
Variable values ending in a `\` are continued on the next line in the
85
customary UNIX fashion.
@@ -827,7 +827,7 @@ color.diff::
827
commands will only use color when output is to the terminal.
828
Defaults to false.
829
+
830
-This does not affect linkgit:git-format-patch[1] nor the
830
+This does not affect linkgit:git-format-patch[1] or the
831
'git-diff-{asterisk}' plumbing commands. Can be overridden on the
832
command line with the `--color[=<when>]` option.
833
Documentation/diff-generate-patch.txt
+1
-1
@@ -174,7 +174,7 @@ added, from the point of view of that parent).
174
In the above example output, the function signature was changed
175
from both files (hence two `-` removals from both file1 and
176
file2, plus `++` to mean one line that was added does not appear
177
-in either file1 nor file2). Also eight other lines are the same
177
+in either file1 or file2). Also eight other lines are the same
178
from file1 but do not appear in file2 (hence prefixed with `+`).
179
180
When shown by `git diff-tree -c`, it compares the parents of a
Documentation/diff-options.txt
+1
-1
@@ -358,7 +358,7 @@ endif::git-log[]
358
--irreversible-delete::
359
Omit the preimage for deletes, i.e. print only the header but not
360
the diff between the preimage and `/dev/null`. The resulting patch
361
- is not meant to be applied with `patch` nor `git apply`; this is
361
+ is not meant to be applied with `patch` or `git apply`; this is
362
solely for people who want to just concentrate on reviewing the
363
text after the change. In addition, the output obviously lack
364
enough information to apply such a patch in reverse, even manually,
Documentation/everyday.txt
+1
-1
@@ -263,7 +263,7 @@ that are not quite ready.
263
<5> create topic branch as needed and apply, again with my
264
sign-offs.
265
<6> rebase internal topic branch that has not been merged to the
266
-master, nor exposed as a part of a stable branch.
266
+master or exposed as a part of a stable branch.
267
<7> restart `pu` every time from the next.
268
<8> and bundle topic branches still cooking.
269
<9> backport a critical fix.
Documentation/git-add.txt
+2
-2
@@ -296,9 +296,9 @@ patch::
296
297
y - stage this hunk
298
n - do not stage this hunk
299
- q - quit; do not stage this hunk nor any of the remaining ones
299
+ q - quit; do not stage this hunk or any of the remaining ones
300
a - stage this hunk and all later hunks in the file
301
- d - do not stage this hunk nor any of the later hunks in the file
301
+ d - do not stage this hunk or any of the later hunks in the file
302
g - select a hunk to go to
303
/ - search for a hunk matching the given regex
304
j - leave this hunk undecided, see next undecided hunk
Documentation/git-count-objects.txt
+2
-2
@@ -33,8 +33,8 @@ size-pack: disk space consumed by the packs, in KiB (unless -H is specified)
33
prune-packable: the number of loose objects that are also present in
34
the packs. These objects could be pruned using `git prune-packed`.
35
+
36
-garbage: the number of files in object database that are not valid
37
-loose objects nor valid packs
36
+garbage: the number of files in object database that are neither valid loose
37
+objects nor valid packs
38
+
39
size-garbage: disk space consumed by garbage files, in KiB (unless -H is
40
specified)
Documentation/git-diff.txt
+2
-2
@@ -158,8 +158,8 @@ $ git diff --name-status <2>
158
$ git diff arch/i386 include/asm-i386 <3>
159
------------
160
+
161
-<1> Show only modification, rename and copy, but not addition
162
-nor deletion.
161
+<1> Show only modification, rename, and copy, but not addition
162
+or deletion.
163
<2> Show only names and the nature of change, but not actual
164
diff output.
165
<3> Limit diff output to named subtrees.
Documentation/git-prune.txt
+1
-1
@@ -56,7 +56,7 @@ OPTIONS
56
EXAMPLE
57
-------
58
59
-To prune objects not used by your repository nor another that
59
+To prune objects not used by your repository or another that
60
borrows from your repository via its
61
`.git/objects/info/alternates`:
62
Documentation/git-push.txt
+1
-1
@@ -385,7 +385,7 @@ will now start building on top of B.
385
The command by default does not allow an update that is not a fast-forward
386
to prevent such loss of history.
387
388
-If you do not want to lose your work (history from X to B) nor the work by
388
+If you do not want to lose your work (history from X to B) or the work by
389
the other person (history from X to A), you would need to first fetch the
390
history from the repository, create a history that contains changes done
391
by both parties, and push the result back.
Documentation/git-read-tree.txt
+1
-1
@@ -57,7 +57,7 @@ OPTIONS
57
-n::
58
--dry-run::
59
Check if the command would error out, without updating the index
60
- nor the files in the working tree for real.
60
+ or the files in the working tree for real.
61
62
-v::
63
Show the progress of checking files out.
Documentation/git-reset.txt
+3
-3
@@ -21,7 +21,7 @@ to HEAD in all forms.
21
22
'git reset' [-q] [<tree-ish>] [--] <paths>...::
23
This form resets the index entries for all <paths> to their
24
- state at <tree-ish>. (It does not affect the working tree, nor
24
+ state at <tree-ish>. (It does not affect the working tree or
25
the current branch.)
26
+
27
This means that `git reset <paths>` is the opposite of `git add
@@ -51,7 +51,7 @@ section of linkgit:git-add[1] to learn how to operate the `--patch` mode.
51
+
52
--
53
--soft::
54
- Does not touch the index file nor the working tree at all (but
54
+ Does not touch the index file or the working tree at all (but
55
resets the head to <commit>, just like all modes do). This leaves
56
all your changed files "Changes to be committed", as 'git status'
57
would put it.
@@ -115,7 +115,7 @@ and changes with these files are distracting.
115
<2> Somebody asks you to pull, and the changes sounds worthy of merging.
116
<3> However, you already dirtied the index (i.e. your index does
117
not match the HEAD commit). But you know the pull you are going
118
-to make does not affect frotz.c nor filfre.c, so you revert the
118
+to make does not affect frotz.c or filfre.c, so you revert the
119
index changes for these two files. Your changes in working tree
120
remain there.
121
<4> Then you can pull and merge, leaving frotz.c and filfre.c
Documentation/git-show-branch.txt
+1
-1
@@ -25,7 +25,7 @@ and/or refs/tags) semi-visually.
25
It cannot show more than 29 branches and commits at a time.
26
27
It uses `showbranch.default` multi-valued configuration items if
28
-no <rev> nor <glob> is given on the command line.
28
+no <rev> or <glob> is given on the command line.
29
30
31
OPTIONS
Documentation/git-show-ref.txt
+1
-1
@@ -89,7 +89,7 @@ OPTIONS
89
Show references matching one or more patterns. Patterns are matched from
90
the end of the full name, and only complete parts are matched, e.g.
91
'master' matches 'refs/heads/master', 'refs/remotes/origin/master',
92
- 'refs/tags/jedi/master' but not 'refs/heads/mymaster' nor
92
+ 'refs/tags/jedi/master' but not 'refs/heads/mymaster' or
93
'refs/remotes/master/jedi'.
94
95
OUTPUT
Documentation/howto/rebase-from-internal-branch.txt
+1
-1
@@ -139,7 +139,7 @@ You fetch from upstream, but not merge.
139
$ git fetch upstream
140
141
This leaves the updated upstream head in .git/FETCH_HEAD but
142
-does not touch your .git/HEAD nor .git/refs/heads/master.
142
+does not touch your .git/HEAD or .git/refs/heads/master.
143
You run "git rebase" now.
144
145
$ git rebase FETCH_HEAD master
Documentation/howto/revert-a-faulty-merge.txt
+2
-2
@@ -54,7 +54,7 @@ where C and D are to fix what was broken in A and B, and you may already
54
have some other changes on the mainline after W.
55
56
If you merge the updated side branch (with D at its tip), none of the
57
-changes made in A nor B will be in the result, because they were reverted
57
+changes made in A or B will be in the result, because they were reverted
58
by W. That is what Alan saw.
59
60
Linus explains the situation:
@@ -90,7 +90,7 @@ with:
90
$ git revert W
91
92
This history would (ignoring possible conflicts between what W and W..Y
93
-changed) be equivalent to not having W nor Y at all in the history:
93
+changed) be equivalent to not having W or Y at all in the history:
94
95
---o---o---o---M---x---x-------x----
96
/
Documentation/howto/revert-branch-rebase.txt
+1
-1
@@ -137,7 +137,7 @@ $ make clean test ;# make sure it did not cause other breakage.
137
------------------------------------------------
138
139
Everything is in the good order. I do not need the temporary branch
140
-nor tag anymore, so remove them:
140
+or tag anymore, so remove them:
141
142
------------------------------------------------
143
$ rm -f .git/refs/tags/pu-anchor
Documentation/merge-options.txt
+7
-8
@@ -63,14 +63,13 @@ merge.
63
64
--squash::
65
--no-squash::
66
- Produce the working tree and index state as if a real
67
- merge happened (except for the merge information),
68
- but do not actually make a commit or
69
- move the `HEAD`, nor record `$GIT_DIR/MERGE_HEAD` to
70
- cause the next `git commit` command to create a merge
71
- commit. This allows you to create a single commit on
72
- top of the current branch whose effect is the same as
73
- merging another branch (or more in case of an octopus).
66
+ Produce the working tree and index state as if a real merge
67
+ happened (except for the merge information), but do not actually
68
+ make a commit, move the `HEAD`, or record `$GIT_DIR/MERGE_HEAD`
69
+ (to cause the next `git commit` command to create a merge
70
+ commit). This allows you to create a single commit on top of
71
+ the current branch whose effect is the same as merging another
72
+ branch (or more in case of an octopus).
73
+
74
With --no-squash perform the merge and commit the result. This
75
option can be used to override --squash.
Documentation/pretty-formats.txt
+1
-1
@@ -78,7 +78,7 @@ The 'raw' format shows the entire commit exactly as
78
stored in the commit object. Notably, the SHA-1s are
79
displayed in full, regardless of whether --abbrev or
80
--no-abbrev are used, and 'parents' information show the
81
-true parent commits, without taking grafts nor history
81
+true parent commits, without taking grafts or history
82
simplification into account.
83
84
* 'format:<string>'
Documentation/pretty-options.txt
+1
-1
@@ -39,7 +39,7 @@ people using 80-column terminals.
39
Show the notes (see linkgit:git-notes[1]) that annotate the
40
commit, when showing the commit log message. This is the default
41
for `git log`, `git show` and `git whatchanged` commands when
42
- there is no `--pretty`, `--format` nor `--oneline` option given
42
+ there is no `--pretty`, `--format`, or `--oneline` option given
43
on the command line.
44
+
45
By default, the notes shown are from the notes refs listed in the
Documentation/rev-list-options.txt
+1
-1
@@ -237,7 +237,7 @@ list.
237
reflog entries from the most recent one to older ones.
238
When this option is used you cannot specify commits to
239
exclude (that is, '{caret}commit', 'commit1..commit2',
240
- nor 'commit1\...commit2' notations cannot be used).
240
+ and 'commit1\...commit2' notations cannot be used).
241
+
242
With `--pretty` format other than `oneline` (for obvious reasons),
243
this causes the output to have two extra lines of information
Documentation/technical/api-gitattributes.txt
+1
-1
@@ -99,7 +99,7 @@ static void setup_check(void)
99
The attribute is Unset, by listing the name of the
100
attribute prefixed with a dash - for the path.
101
} else if (ATTR_UNSET(value)) {
102
- The attribute is not set nor unset for the path.
102
+ The attribute is neither set nor unset for the path.
103
} else if (!strcmp(value, "input")) {
104
If none of ATTR_TRUE(), ATTR_FALSE(), or ATTR_UNSET() is
105
true, the value is a string set in the gitattributes
Documentation/technical/pack-protocol.txt
+4
-4
@@ -237,10 +237,10 @@ The client now sends the maximum commit history depth it wants for
237
this transaction, which is the number of commits it wants from the
238
tip of the history, if any, as a 'deepen' line. A depth of 0 is the
239
same as not making a depth request. The client does not want to receive
240
-any commits beyond this depth, nor objects needed only to complete
241
-those commits. Commits whose parents are not received as a result are
242
-defined as shallow and marked as such in the server. This information
243
-is sent back to the client in the next step.
240
+any commits beyond this depth, nor does it want objects needed only to
241
+complete those commits. Commits whose parents are not received as a
242
+result are defined as shallow and marked as such in the server. This
243
+information is sent back to the client in the next step.
244
245
Once all the 'want's and 'shallow's (and optional 'deepen') are
246
transferred, clients MUST send a flush-pkt, to tell the server side
Documentation/technical/protocol-common.txt
+1
-1
@@ -39,7 +39,7 @@ More specifically, they:
39
caret `^`, colon `:`, question-mark `?`, asterisk `*`,
40
or open bracket `[` anywhere.
41
42
-. They cannot end with a slash `/` nor a dot `.`.
42
+. They cannot end with a slash `/` or a dot `.`.
43
44
. They cannot end with the sequence `.lock`.
45
Documentation/user-manual.txt
+1
-1
@@ -4074,7 +4074,7 @@ the `HEAD` tree, and stage 3 to the `$target` tree.
4074
4075
Earlier we said that trivial merges are done inside
4076
`git read-tree -m`. For example, if the file did not change
4077
-from `$orig` to `HEAD` nor `$target`, or if the file changed
4077
+from `$orig` to `HEAD` or `$target`, or if the file changed
4078
from `$orig` to `HEAD` and `$orig` to `$target` the same way,
4079
obviously the final outcome is what is in `HEAD`. What the
4080
above example shows is that file `hello.c` was changed from