| uploadpack.hideRefs:: |
| This variable is the same as `transfer.hideRefs`, but applies |
| only to `upload-pack` (and so affects only fetches, not pushes). |
| An attempt to fetch a hidden ref by `git fetch` will fail. See |
| also `uploadpack.allowTipSHA1InWant`. |
| |
| uploadpack.allowTipSHA1InWant:: |
| When `uploadpack.hideRefs` is in effect, allow `upload-pack` |
| to accept a fetch request that asks for an object at the tip |
| of a hidden ref (by default, such a request is rejected). |
| See also `uploadpack.hideRefs`. Even if this is false, a client |
| may be able to steal objects via the techniques described in the |
| "SECURITY" section of the linkgit:gitnamespaces[7] man page; it's |
| best to keep private data in a separate repository. |
| |
| uploadpack.allowReachableSHA1InWant:: |
| Allow `upload-pack` to accept a fetch request that asks for an |
| object that is reachable from any ref tip. However, note that |
| calculating object reachability is computationally expensive. |
| Defaults to `false`. Even if this is false, a client may be able |
| to steal objects via the techniques described in the "SECURITY" |
| section of the linkgit:gitnamespaces[7] man page; it's best to |
| keep private data in a separate repository. |
| |
| uploadpack.allowAnySHA1InWant:: |
| Allow `upload-pack` to accept a fetch request that asks for any |
| object at all. |
| Defaults to `false`. |
| |
| uploadpack.keepAlive:: |
| When `upload-pack` has started `pack-objects`, there may be a |
| quiet period while `pack-objects` prepares the pack. Normally |
| it would output progress information, but if `--quiet` was used |
| for the fetch, `pack-objects` will output nothing at all until |
| the pack data begins. Some clients and networks may consider |
| the server to be hung and give up. Setting this option instructs |
| `upload-pack` to send an empty keepalive packet every |
| `uploadpack.keepAlive` seconds. Setting this option to 0 |
| disables keepalive packets entirely. The default is 5 seconds. |
| |
| uploadpack.packObjectsHook:: |
| If this option is set, when `upload-pack` would run |
| `git pack-objects` to create a packfile for a client, it will |
| run this shell command instead. The `pack-objects` command and |
| arguments it _would_ have run (including the `git pack-objects` |
| at the beginning) are appended to the shell command. The stdin |
| and stdout of the hook are treated as if `pack-objects` itself |
| was run. I.e., `upload-pack` will feed input intended for |
| `pack-objects` to the hook, and expects a completed packfile on |
| stdout. |
| + |
| Note that this configuration variable is ignored if it is seen in the |
| repository-level config (this is a safety measure against fetching from |
| untrusted repositories). |
| |
| uploadpack.allowFilter:: |
| If this option is set, `upload-pack` will support partial |
| clone and partial fetch object filtering. |
| |
| uploadpackfilter.allow:: |
| Provides a default value for unspecified object filters (see: the |
| below configuration variable). If set to `true`, this will also |
| enable all filters which get added in the future. |
| Defaults to `true`. |
| |
| uploadpackfilter.<filter>.allow:: |
| Explicitly allow or ban the object filter corresponding to |
| `<filter>`, where `<filter>` may be one of: `blob:none`, |
| `blob:limit`, `object:type`, `tree`, `sparse:oid`, or `combine`. |
| If using combined filters, both `combine` and all of the nested |
| filter kinds must be allowed. Defaults to `uploadpackfilter.allow`. |
| |
| uploadpackfilter.tree.maxDepth:: |
| Only allow `--filter=tree:<n>` when `<n>` is no more than the value of |
| `uploadpackfilter.tree.maxDepth`. If set, this also implies |
| `uploadpackfilter.tree.allow=true`, unless this configuration |
| variable had already been set. Has no effect if unset. |
| |
| uploadpack.allowRefInWant:: |
| If this option is set, `upload-pack` will support the `ref-in-want` |
| feature of the protocol version 2 `fetch` command. This feature |
| is intended for the benefit of load-balanced servers which may |
| not have the same view of what OIDs their refs point to due to |
| replication delay. |