E.g.: my_function () {
- As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
- [::], [==], nor [..]) for portability.
+ [::], [==], or [..]) for portability.
- We do not use \{m,n\};
- We do not use -E;
- - We do not use ? nor + (which are \{0,1\} and \{1,\}
+ - We do not use ? or + (which are \{0,1\} and \{1,\}
respectively in BRE) but that goes without saying as these
are ERE elements not BRE (note that \? and \+ are not even part
of BRE -- making them accessible from BRE is a GNU extension).
The following escape sequences (beside `\"` and `\\`) are recognized:
`\n` for newline character (NL), `\t` for horizontal tabulation (HT, TAB)
-and `\b` for backspace (BS). No other char escape sequence, nor octal
-char sequences are valid.
+and `\b` for backspace (BS). Other char escape sequences (including octal
+escape sequences) are invalid.
Variable values ending in a `\` are continued on the next line in the
customary UNIX fashion.
commands will only use color when output is to the terminal.
Defaults to false.
+
-This does not affect linkgit:git-format-patch[1] nor the
+This does not affect linkgit:git-format-patch[1] or the
'git-diff-{asterisk}' plumbing commands. Can be overridden on the
command line with the `--color[=<when>]` option.
In the above example output, the function signature was changed
from both files (hence two `-` removals from both file1 and
file2, plus `++` to mean one line that was added does not appear
-in either file1 nor file2). Also eight other lines are the same
+in either file1 or file2). Also eight other lines are the same
from file1 but do not appear in file2 (hence prefixed with `+`).
When shown by `git diff-tree -c`, it compares the parents of a
--irreversible-delete::
Omit the preimage for deletes, i.e. print only the header but not
the diff between the preimage and `/dev/null`. The resulting patch
- is not meant to be applied with `patch` nor `git apply`; this is
+ is not meant to be applied with `patch` or `git apply`; this is
solely for people who want to just concentrate on reviewing the
text after the change. In addition, the output obviously lack
enough information to apply such a patch in reverse, even manually,
<5> create topic branch as needed and apply, again with my
sign-offs.
<6> rebase internal topic branch that has not been merged to the
-master, nor exposed as a part of a stable branch.
+master or exposed as a part of a stable branch.
<7> restart `pu` every time from the next.
<8> and bundle topic branches still cooking.
<9> backport a critical fix.
y - stage this hunk
n - do not stage this hunk
- q - quit; do not stage this hunk nor any of the remaining ones
+ q - quit; do not stage this hunk or any of the remaining ones
a - stage this hunk and all later hunks in the file
- d - do not stage this hunk nor any of the later hunks in the file
+ d - do not stage this hunk or any of the later hunks in the file
g - select a hunk to go to
/ - search for a hunk matching the given regex
j - leave this hunk undecided, see next undecided hunk
prune-packable: the number of loose objects that are also present in
the packs. These objects could be pruned using `git prune-packed`.
+
-garbage: the number of files in object database that are not valid
-loose objects nor valid packs
+garbage: the number of files in object database that are neither valid loose
+objects nor valid packs
+
size-garbage: disk space consumed by garbage files, in KiB (unless -H is
specified)
$ git diff arch/i386 include/asm-i386 <3>
------------
+
-<1> Show only modification, rename and copy, but not addition
-nor deletion.
+<1> Show only modification, rename, and copy, but not addition
+or deletion.
<2> Show only names and the nature of change, but not actual
diff output.
<3> Limit diff output to named subtrees.
EXAMPLE
-------
-To prune objects not used by your repository nor another that
+To prune objects not used by your repository or another that
borrows from your repository via its
`.git/objects/info/alternates`:
The command by default does not allow an update that is not a fast-forward
to prevent such loss of history.
-If you do not want to lose your work (history from X to B) nor the work by
+If you do not want to lose your work (history from X to B) or the work by
the other person (history from X to A), you would need to first fetch the
history from the repository, create a history that contains changes done
by both parties, and push the result back.
-n::
--dry-run::
Check if the command would error out, without updating the index
- nor the files in the working tree for real.
+ or the files in the working tree for real.
-v::
Show the progress of checking files out.
'git reset' [-q] [<tree-ish>] [--] <paths>...::
This form resets the index entries for all <paths> to their
- state at <tree-ish>. (It does not affect the working tree, nor
+ state at <tree-ish>. (It does not affect the working tree or
the current branch.)
+
This means that `git reset <paths>` is the opposite of `git add
+
--
--soft::
- Does not touch the index file nor the working tree at all (but
+ Does not touch the index file or the working tree at all (but
resets the head to <commit>, just like all modes do). This leaves
all your changed files "Changes to be committed", as 'git status'
would put it.
<2> Somebody asks you to pull, and the changes sounds worthy of merging.
<3> However, you already dirtied the index (i.e. your index does
not match the HEAD commit). But you know the pull you are going
-to make does not affect frotz.c nor filfre.c, so you revert the
+to make does not affect frotz.c or filfre.c, so you revert the
index changes for these two files. Your changes in working tree
remain there.
<4> Then you can pull and merge, leaving frotz.c and filfre.c
It cannot show more than 29 branches and commits at a time.
It uses `showbranch.default` multi-valued configuration items if
-no <rev> nor <glob> is given on the command line.
+no <rev> or <glob> is given on the command line.
OPTIONS
Show references matching one or more patterns. Patterns are matched from
the end of the full name, and only complete parts are matched, e.g.
'master' matches 'refs/heads/master', 'refs/remotes/origin/master',
- 'refs/tags/jedi/master' but not 'refs/heads/mymaster' nor
+ 'refs/tags/jedi/master' but not 'refs/heads/mymaster' or
'refs/remotes/master/jedi'.
OUTPUT
$ git fetch upstream
This leaves the updated upstream head in .git/FETCH_HEAD but
-does not touch your .git/HEAD nor .git/refs/heads/master.
+does not touch your .git/HEAD or .git/refs/heads/master.
You run "git rebase" now.
$ git rebase FETCH_HEAD master
have some other changes on the mainline after W.
If you merge the updated side branch (with D at its tip), none of the
-changes made in A nor B will be in the result, because they were reverted
+changes made in A or B will be in the result, because they were reverted
by W. That is what Alan saw.
Linus explains the situation:
$ git revert W
This history would (ignoring possible conflicts between what W and W..Y
-changed) be equivalent to not having W nor Y at all in the history:
+changed) be equivalent to not having W or Y at all in the history:
---o---o---o---M---x---x-------x----
/
------------------------------------------------
Everything is in the good order. I do not need the temporary branch
-nor tag anymore, so remove them:
+or tag anymore, so remove them:
------------------------------------------------
$ rm -f .git/refs/tags/pu-anchor
--squash::
--no-squash::
- Produce the working tree and index state as if a real
- merge happened (except for the merge information),
- but do not actually make a commit or
- move the `HEAD`, nor record `$GIT_DIR/MERGE_HEAD` to
- cause the next `git commit` command to create a merge
- commit. This allows you to create a single commit on
- top of the current branch whose effect is the same as
- merging another branch (or more in case of an octopus).
+ Produce the working tree and index state as if a real merge
+ happened (except for the merge information), but do not actually
+ make a commit, move the `HEAD`, or record `$GIT_DIR/MERGE_HEAD`
+ (to cause the next `git commit` command to create a merge
+ commit). This allows you to create a single commit on top of
+ the current branch whose effect is the same as merging another
+ branch (or more in case of an octopus).
+
With --no-squash perform the merge and commit the result. This
option can be used to override --squash.
stored in the commit object. Notably, the SHA-1s are
displayed in full, regardless of whether --abbrev or
--no-abbrev are used, and 'parents' information show the
-true parent commits, without taking grafts nor history
+true parent commits, without taking grafts or history
simplification into account.
* 'format:<string>'
Show the notes (see linkgit:git-notes[1]) that annotate the
commit, when showing the commit log message. This is the default
for `git log`, `git show` and `git whatchanged` commands when
- there is no `--pretty`, `--format` nor `--oneline` option given
+ there is no `--pretty`, `--format`, or `--oneline` option given
on the command line.
+
By default, the notes shown are from the notes refs listed in the
reflog entries from the most recent one to older ones.
When this option is used you cannot specify commits to
exclude (that is, '{caret}commit', 'commit1..commit2',
- nor 'commit1\...commit2' notations cannot be used).
+ and 'commit1\...commit2' notations cannot be used).
+
With `--pretty` format other than `oneline` (for obvious reasons),
this causes the output to have two extra lines of information
The attribute is Unset, by listing the name of the
attribute prefixed with a dash - for the path.
} else if (ATTR_UNSET(value)) {
- The attribute is not set nor unset for the path.
+ The attribute is neither set nor unset for the path.
} else if (!strcmp(value, "input")) {
If none of ATTR_TRUE(), ATTR_FALSE(), or ATTR_UNSET() is
true, the value is a string set in the gitattributes
this transaction, which is the number of commits it wants from the
tip of the history, if any, as a 'deepen' line. A depth of 0 is the
same as not making a depth request. The client does not want to receive
-any commits beyond this depth, nor objects needed only to complete
-those commits. Commits whose parents are not received as a result are
-defined as shallow and marked as such in the server. This information
-is sent back to the client in the next step.
+any commits beyond this depth, nor does it want objects needed only to
+complete those commits. Commits whose parents are not received as a
+result are defined as shallow and marked as such in the server. This
+information is sent back to the client in the next step.
Once all the 'want's and 'shallow's (and optional 'deepen') are
transferred, clients MUST send a flush-pkt, to tell the server side
caret `^`, colon `:`, question-mark `?`, asterisk `*`,
or open bracket `[` anywhere.
-. They cannot end with a slash `/` nor a dot `.`.
+. They cannot end with a slash `/` or a dot `.`.
. They cannot end with the sequence `.lock`.
Earlier we said that trivial merges are done inside
`git read-tree -m`. For example, if the file did not change
-from `$orig` to `HEAD` nor `$target`, or if the file changed
+from `$orig` to `HEAD` or `$target`, or if the file changed
from `$orig` to `HEAD` and `$orig` to `$target` the same way,
obviously the final outcome is what is in `HEAD`. What the
above example shows is that file `hello.c` was changed from