Do: [-q | --quiet]
Don't: [-q|--quiet]
- Don't use spacing around "|" tokens when they're used to seperate the
+ Don't use spacing around "|" tokens when they're used to separate the
alternate arguments of an option:
Do: --track[=(direct|inherit)]
Don't: --track[=(direct | inherit)]
the resolution of these conditions (thus, prohibiting them from
declaring remote URLs).
+
-As for the naming of this keyword, it is for forwards compatibiliy with
+As for the naming of this keyword, it is for forwards compatibility with
a naming scheme that supports more variable-based include conditions,
but currently Git only supports the exact keyword described above.
myuser:$5$.NqmNH1vwfzGpV8B$znZIcumu1tNLATgV2l6e1/mY8RzhUDHMOaVOeL1cxV3
------
You can use the 'htpasswd' facility that comes with Apache to make these
-files, but only with the -d option (or -B if your system suports it).
+files, but only with the -d option (or -B if your system supports it).
Preferably use the system specific utility that manages password hash
creation in your platform (e.g. mkpasswd in Linux, encrypt in OpenBSD or
The number of additional commits is the number
of commits which would be displayed by "git log v1.0.4..parent".
-The hash suffix is "-g" + an unambigous abbreviation for the tip commit
+The hash suffix is "-g" + an unambiguous abbreviation for the tip commit
of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`). The
length of the abbreviation scales as the repository grows, using the
approximate number of objects in the repository and a bit of math
Tree objects as well as tag objects not pointing at commits, cannot be described.
When describing blobs, the lightweight tags pointing at blobs are ignored,
-but the blob is still described as <commit
t-ish>:<path> despite the lightweight
+but the blob is still described as <commit-ish>:<path> despite the lightweight
tag being favorable.
GIT
or "--reroll-count=4rev2" are allowed), but the downside of
using such a reroll-count is that the range-diff/interdiff
with the previous version does not state exactly which
- version the new interation is compared against.
+ version the new iteration is compared against.
--to=<email>::
Add a `To:` header to the email headers. This is in addition
-----------
Various values from structured fields can be used to interpolate
-into the resulting output. For each outputing line, the following
+into the resulting output. For each outputting line, the following
names can be used:
objectmode::
Extra headers in the object are also an error under mktag, but ignored
by linkgit:git-fsck[1]. This extra check can be turned off by setting
-the appropriate `fsck.<msg-id>` varible:
+the appropriate `fsck.<msg-id>` variable:
git -c fsck.extraHeaderEntry=ignore mktag <my-tag-with-headers
problem above? Also, if it suggests paths, what if the user has a
file or directory that begins with either a '!' or '#' or has a '*',
'\', '?', '[', or ']' in its name? And if it suggests paths, will
- it complete "/pro" to "/proc" (in the root filesytem) rather than to
+ it complete "/pro" to "/proc" (in the root filesystem) rather than to
"/progress.txt" in the current directory? (Note that users are
likely to want to start paths with a leading '/' in non-cone mode,
for the same reason that .gitignore files often have one.)
# ... hack hack hack ...
$ git add --patch foo # add unrelated changes to the index
$ git stash push --staged # save these changes to the stash
-# ... hack hack hack, finish curent changes ...
+# ... hack hack hack, finish current changes ...
$ git commit -m 'Massive' # commit fully tested changes
$ git switch fixup-branch # switch to another branch
$ git stash pop # to finish work on the saved changes
The above configuration expects your public repositories to live under
`/pub/git` and will serve them as `http://git.domain.org/dir-under-pub-git`,
-both as clonable Git URL and as browseable gitweb interface. If you then
+both as clonable Git URL and as browsable gitweb interface. If you then
start your linkgit:git-daemon[1] with `--base-path=/pub/git --export-all`
then you can even use the `git://` URL with exactly the same path.
renames for any files within a directory that was renamed, in which
case we will not have been able to detect any rename for the directory
itself. In such a case, we do not know whether the directory was
-renamed; we want to be careful to avoid cacheing some kind of "this
+renamed; we want to be careful to avoid caching some kind of "this
directory was not renamed" statement. If we did, then a subsequent
commit being rebased could add a file to the old directory, and the
user would expect it to end up in the correct directory -- something
The `<pushurl>` is used for pushes only. It is optional and defaults
to `<URL>`. Pushing to a remote affects all defined pushurls or to all
defined urls if no pushurls are defined. Fetch, however, will only
-fetch from the first defined url if muliple urls are defined.
+fetch from the first defined url if multiple urls are defined.
Named file in `$GIT_DIR/remotes`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
projects / thirdparty / git.git / commitdiff
