mirror of
https://github.com/git/git
synced 2024-08-24 18:26:02 +00:00
Fix typos in technical documentation.
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
parent
b0883aa6c7
commit
6a5d0b0a90
|
@ -19,7 +19,7 @@ git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>...]::
|
|||
git-diff-files [<pattern>...]::
|
||||
compares the index and the files on the filesystem.
|
||||
|
||||
The "git-diff-tree" command begins its ouput by printing the hash of
|
||||
The "git-diff-tree" command begins its output by printing the hash of
|
||||
what is being compared. After that, all the commands print one output
|
||||
line per changed file.
|
||||
|
||||
|
|
|
@ -799,7 +799,7 @@ fixed in the "main" branch by commit "F"?
|
|||
The result of such a bisection would be that we would find that H is
|
||||
the first bad commit, when in fact it's B. So that would be wrong!
|
||||
|
||||
And yes it's can happen in practice that people working on one branch
|
||||
And yes it can happen in practice that people working on one branch
|
||||
are not aware that people working on another branch fixed a bug! It
|
||||
could also happen that F fixed more than one bug or that it is a
|
||||
revert of some big development effort that was not ready to be
|
||||
|
|
|
@ -37,7 +37,7 @@ unsigned, with 'verbatim', they will be silently exported
|
|||
and with 'warn', they will be exported, but you will see a warning.
|
||||
|
||||
--tag-of-filtered-object=(abort|drop|rewrite)::
|
||||
Specify how to handle tags whose tagged objectis filtered out.
|
||||
Specify how to handle tags whose tagged object is filtered out.
|
||||
Since revisions and files to export can be limited by path,
|
||||
tagged objects may be filtered completely.
|
||||
+
|
||||
|
|
|
@ -152,7 +152,7 @@ fast-forward update, fast-import will skip updating that ref and instead
|
|||
prints a warning message. fast-import will always attempt to update all
|
||||
branch refs, and does not stop on the first failure.
|
||||
|
||||
Branch updates can be forced with \--force, but its recommended that
|
||||
Branch updates can be forced with \--force, but it's recommended that
|
||||
this only be used on an otherwise quiet repository. Using \--force
|
||||
is not necessary for an initial import into an empty repository.
|
||||
|
||||
|
@ -267,7 +267,7 @@ is always copied into the identity string at the time it is being
|
|||
created by fast-import. There is no way to specify a different time or
|
||||
timezone.
|
||||
+
|
||||
This particular format is supplied as its short to implement and
|
||||
This particular format is supplied as it's short to implement and
|
||||
may be useful to a process that wants to create a new commit
|
||||
right now, without needing to use a working directory or
|
||||
'git update-index'.
|
||||
|
@ -420,7 +420,7 @@ quoting or escaping syntax is supported within `<committish>`.
|
|||
Here `<committish>` is any of the following:
|
||||
|
||||
* The name of an existing branch already in fast-import's internal branch
|
||||
table. If fast-import doesn't know the name, its treated as a SHA-1
|
||||
table. If fast-import doesn't know the name, it's treated as a SHA-1
|
||||
expression.
|
||||
|
||||
* A mark reference, `:<idnum>`, where `<idnum>` is the mark number.
|
||||
|
@ -759,7 +759,7 @@ assigned mark.
|
|||
|
||||
The mark command is optional here as some frontends have chosen
|
||||
to generate the Git SHA-1 for the blob on their own, and feed that
|
||||
directly to `commit`. This is typically more work than its worth
|
||||
directly to `commit`. This is typically more work than it's worth
|
||||
however, as marks are inexpensive to store and easy to use.
|
||||
|
||||
`data`
|
||||
|
|
|
@ -14,7 +14,7 @@ DESCRIPTION
|
|||
-----------
|
||||
A simple CGI program to serve the contents of a Git repository to Git
|
||||
clients accessing the repository over http:// and https:// protocols.
|
||||
The program supports clients fetching using both the smart HTTP protcol
|
||||
The program supports clients fetching using both the smart HTTP protocol
|
||||
and the backwards-compatible dumb HTTP protocol, as well as clients
|
||||
pushing using the smart HTTP protocol.
|
||||
|
||||
|
|
|
@ -25,7 +25,7 @@ Commands are given by the caller on the helper's standard input, one per line.
|
|||
|
||||
'capabilities'::
|
||||
Lists the capabilities of the helper, one per line, ending
|
||||
with a blank line. Each capability may be preceeded with '*'.
|
||||
with a blank line. Each capability may be preceded with '*'.
|
||||
This marks them mandatory for git version using the remote
|
||||
helper to understand (unknown mandatory capability is fatal
|
||||
error).
|
||||
|
|
|
@ -33,7 +33,7 @@ OPTIONS
|
|||
--stop-at-non-option::
|
||||
Only meaningful in `--parseopt` mode. Lets the option parser stop at
|
||||
the first non-option argument. This can be used to parse sub-commands
|
||||
that take options themself.
|
||||
that take options themselves.
|
||||
|
||||
--sq-quote::
|
||||
Use 'git rev-parse' in shell quoting mode (see SQ-QUOTE
|
||||
|
|
|
@ -218,7 +218,7 @@ OPTIONS
|
|||
This option is only valid for the update command.
|
||||
Rebase the current branch onto the commit recorded in the
|
||||
superproject. If this option is given, the submodule's HEAD will not
|
||||
be detached. If a a merge failure prevents this process, you will have
|
||||
be detached. If a merge failure prevents this process, you will have
|
||||
to resolve these failures with linkgit:git-rebase[1].
|
||||
If the key `submodule.$name.update` is set to `rebase`, this option is
|
||||
implicit.
|
||||
|
|
|
@ -233,27 +233,27 @@ endif::git-rev-list[]
|
|||
Pretend as if all the refs in `$GIT_DIR/refs/heads` are listed
|
||||
on the command line as '<commit>'. If `pattern` is given, limit
|
||||
branches to ones matching given shell glob. If pattern lacks '?',
|
||||
'*', or '[', '/*' at the end is impiled.
|
||||
'*', or '[', '/*' at the end is implied.
|
||||
|
||||
--tags[=pattern]::
|
||||
|
||||
Pretend as if all the refs in `$GIT_DIR/refs/tags` are listed
|
||||
on the command line as '<commit>'. If `pattern` is given, limit
|
||||
tags to ones matching given shell glob. If pattern lacks '?', '*',
|
||||
or '[', '/*' at the end is impiled.
|
||||
or '[', '/*' at the end is implied.
|
||||
|
||||
--remotes[=pattern]::
|
||||
|
||||
Pretend as if all the refs in `$GIT_DIR/refs/remotes` are listed
|
||||
on the command line as '<commit>'. If `pattern`is given, limit
|
||||
remote tracking branches to ones matching given shell glob.
|
||||
If pattern lacks '?', '*', or '[', '/*' at the end is impiled.
|
||||
If pattern lacks '?', '*', or '[', '/*' at the end is implied.
|
||||
|
||||
--glob=glob-pattern::
|
||||
Pretend as if all the refs matching shell glob `glob-pattern`
|
||||
are listed on the command line as '<commit>'. Leading 'refs/',
|
||||
is automatically prepended if missing. If pattern lacks '?', '*',
|
||||
or '[', '/*' at the end is impiled.
|
||||
or '[', '/*' at the end is implied.
|
||||
|
||||
|
||||
ifndef::git-rev-list[]
|
||||
|
|
|
@ -51,7 +51,7 @@ The functions above do the following:
|
|||
ENOENT; a diagnostic is printed only if .silent_exec_failure is 0.
|
||||
|
||||
. Otherwise, the program is run. If it terminates regularly, its exit
|
||||
code is returned. No diagnistic is printed, even if the exit code is
|
||||
code is returned. No diagnostic is printed, even if the exit code is
|
||||
non-zero.
|
||||
|
||||
. If the program terminated due to a signal, then the return value is the
|
||||
|
|
|
@ -149,7 +149,7 @@ advertisement list at all, but other refs may still appear.
|
|||
The stream MUST include capability declarations behind a NUL on the
|
||||
first ref. The peeled value of a ref (that is "ref^{}") MUST be
|
||||
immediately after the ref itself, if presented. A conforming server
|
||||
MUST peel the ref if its an annotated tag.
|
||||
MUST peel the ref if it's an annotated tag.
|
||||
|
||||
----
|
||||
advertised-refs = (no-refs / list-of-refs)
|
||||
|
@ -261,7 +261,7 @@ Without either multi_ack or multi_ack_detailed:
|
|||
|
||||
* upload-pack sends "NAK" on a flush-pkt if no common object
|
||||
has been found yet. If one has been found, and thus an ACK
|
||||
was already sent, its silent on the flush-pkt.
|
||||
was already sent, it's silent on the flush-pkt.
|
||||
|
||||
After the client has gotten enough ACK responses that it can determine
|
||||
that the server has enough information to send an efficient packfile
|
||||
|
@ -271,9 +271,9 @@ as common with the server, or the --date-order queue is empty), or the
|
|||
client determines that it wants to give up (in the canonical implementation,
|
||||
this is determined when the client sends 256 'have' lines without getting
|
||||
any of them ACKed by the server - meaning there is nothing in common and
|
||||
the server should just send all it's objects), then the client will send
|
||||
the server should just send all of its objects), then the client will send
|
||||
a 'done' command. The 'done' command signals to the server that the client
|
||||
is ready to receive it's packfile data.
|
||||
is ready to receive its packfile data.
|
||||
|
||||
However, the 256 limit *only* turns on in the canonical client
|
||||
implementation if we have received at least one "ACK %s continue"
|
||||
|
@ -286,7 +286,7 @@ ACK after 'done' if there is at least one common base and multi_ack or
|
|||
multi_ack_detailed is enabled. The server always sends NAK after 'done'
|
||||
if there is no common base found.
|
||||
|
||||
Then the server will start sending it's packfile data.
|
||||
Then the server will start sending its packfile data.
|
||||
|
||||
----
|
||||
server-response = *ack_multi ack / nak
|
||||
|
|
|
@ -60,7 +60,7 @@ doesn't, as in the following diagram:
|
|||
If the client wants x,y and starts out by saying have F,S, the server
|
||||
doesn't know what F,S is. Eventually the client says "have d" and
|
||||
the server sends "ACK d continue" to let the client know to stop
|
||||
walking down that line (so don't send c-b-a), but its not done yet,
|
||||
walking down that line (so don't send c-b-a), but it's not done yet,
|
||||
it needs a base for x. The client keeps going with S-R-Q, until a
|
||||
gets reached, at which point the server has a clear base and it all
|
||||
ends.
|
||||
|
@ -181,7 +181,7 @@ delete-refs
|
|||
-----------
|
||||
|
||||
If the server sends back the 'delete-refs' capability, it means that
|
||||
it is capable of accepting an zero-id value as the target
|
||||
it is capable of accepting a zero-id value as the target
|
||||
value of a reference update. It is not sent back by the client, it
|
||||
simply informs the client that it can be sent zero-id values
|
||||
to delete references.
|
||||
|
|
|
@ -1196,7 +1196,7 @@ the time, you will want to commit your changes before you can merge,
|
|||
and if you don't, then linkgit:git-stash[1] can take these changes
|
||||
away while you're doing the merge, and reapply them afterwards.
|
||||
|
||||
If the changes are independant enough, Git will automatically complete
|
||||
If the changes are independent enough, Git will automatically complete
|
||||
the merge and commit the result (or reuse an existing commit in case
|
||||
of <<fast-forwards,fast-forward>>, see below). On the other hand,
|
||||
if there are conflicts--for example, if the same file is
|
||||
|
|
Loading…
Reference in a new issue