[verse]
'git-upload-pack' [--[no-]strict] [--timeout=<n>] [--stateless-rpc]
[--advertise-refs] <directory>
+
DESCRIPTION
-----------
Invoked by 'git fetch-pack', learns what
of Git object directories which can be used to search for Git
objects. New objects will not be written to these directories.
+
- Entries that begin with `"` (double-quote) will be interpreted
- as C-style quoted paths, removing leading and trailing
- double-quotes and respecting backslash escapes. E.g., the value
- `"path-with-\"-and-:-in-it":vanilla-path` has two paths:
- `path-with-"-and-:-in-it` and `vanilla-path`.
+Entries that begin with `"` (double-quote) will be interpreted
+as C-style quoted paths, removing leading and trailing
+double-quotes and respecting backslash escapes. E.g., the value
+`"path-with-\"-and-:-in-it":vanilla-path` has two paths:
+`path-with-"-and-:-in-it` and `vanilla-path`.
`GIT_DIR`::
If the `GIT_DIR` environment variable is set then it
attribute. If you decide to use the `working-tree-encoding` attribute
in your repository, then it is strongly recommended to ensure that all
clients working with the repository support it.
-
- For example, Microsoft Visual Studio resources files (`*.rc`) or
- PowerShell script files (`*.ps1`) are sometimes encoded in UTF-16.
- If you declare `*.ps1` as files as UTF-16 and you add `foo.ps1` with
- a `working-tree-encoding` enabled Git client, then `foo.ps1` will be
- stored as UTF-8 internally. A client without `working-tree-encoding`
- support will checkout `foo.ps1` as UTF-8 encoded file. This will
- typically cause trouble for the users of this file.
-
- If a Git client, that does not support the `working-tree-encoding`
- attribute, adds a new file `bar.ps1`, then `bar.ps1` will be
- stored "as-is" internally (in this example probably as UTF-16).
- A client with `working-tree-encoding` support will interpret the
- internal contents as UTF-8 and try to convert it to UTF-16 on checkout.
- That operation will fail and cause an error.
++
+For example, Microsoft Visual Studio resources files (`*.rc`) or
+PowerShell script files (`*.ps1`) are sometimes encoded in UTF-16.
+If you declare `*.ps1` as files as UTF-16 and you add `foo.ps1` with
+a `working-tree-encoding` enabled Git client, then `foo.ps1` will be
+stored as UTF-8 internally. A client without `working-tree-encoding`
+support will checkout `foo.ps1` as UTF-8 encoded file. This will
+typically cause trouble for the users of this file.
++
+If a Git client, that does not support the `working-tree-encoding`
+attribute, adds a new file `bar.ps1`, then `bar.ps1` will be
+stored "as-is" internally (in this example probably as UTF-16).
+A client with `working-tree-encoding` support will interpret the
+internal contents as UTF-8 and try to convert it to UTF-16 on checkout.
+That operation will fail and cause an error.
- Reencoding content to non-UTF encodings can cause errors as the
conversion might not be UTF-8 round trip safe. If you suspect your
submodule.<name>.ignore::
Defines under what circumstances "git status" and the diff family show
a submodule as modified. The following values are supported:
-
++
+--
all;; The submodule will never be considered modified (but will
nonetheless show up in the output of status and commit when it has
been staged).
differences, and modifications to tracked and untracked files are
shown. This is the default option.
- If this option is also present in the submodules entry in .git/config
- of the superproject, the setting there will override the one found in
- .gitmodules.
- Both settings can be overridden on the command line by using the
- "--ignore-submodule" option. The 'git submodule' commands are not
- affected by this setting.
+If this option is also present in the submodules entry in .git/config
+of the superproject, the setting there will override the one found in
+.gitmodules.
+
+Both settings can be overridden on the command line by using the
+"--ignore-submodule" option. The 'git submodule' commands are not
+affected by this setting.
+--
submodule.<name>.shallow::
When set to true, a clone of this submodule will be performed as a
A submodule is considered active,
- (a) if `submodule.<name>.active` is set to `true`
- or
- (b) if the submodule's path matches the pathspec in `submodule.active`
- or
- (c) if `submodule.<name>.url` is set.
+ a. if `submodule.<name>.active` is set to `true`
++
+or
+
+ b. if the submodule's path matches the pathspec in `submodule.active`
++
+or
+
+ c. if `submodule.<name>.url` is set.
and these are evaluated in this order.