| 1 | uploadpack.hideRefs:: |
| 2 | This variable is the same as `transfer.hideRefs`, but applies |
| 3 | only to `upload-pack` (and so affects only fetches, not pushes). |
| 4 | An attempt to fetch a hidden ref by `git fetch` will fail. See |
| 5 | also `uploadpack.allowTipSHA1InWant`. |
| 6 | |
| 7 | uploadpack.allowTipSHA1InWant:: |
| 8 | When `uploadpack.hideRefs` is in effect, allow `upload-pack` |
| 9 | to accept a fetch request that asks for an object at the tip |
| 10 | of a hidden ref (by default, such a request is rejected). |
| 11 | See also `uploadpack.hideRefs`. Even if this is false, a client |
| 12 | may be able to steal objects via the techniques described in the |
| 13 | "SECURITY" section of the linkgit:gitnamespaces[7] man page; it's |
| 14 | best to keep private data in a separate repository. |
| 15 | |
| 16 | uploadpack.allowReachableSHA1InWant:: |
| 17 | Allow `upload-pack` to accept a fetch request that asks for an |
| 18 | object that is reachable from any ref tip. However, note that |
| 19 | calculating object reachability is computationally expensive. |
| 20 | Defaults to `false`. Even if this is false, a client may be able |
| 21 | to steal objects via the techniques described in the "SECURITY" |
| 22 | section of the linkgit:gitnamespaces[7] man page; it's best to |
| 23 | keep private data in a separate repository. |
| 24 | |
| 25 | uploadpack.allowAnySHA1InWant:: |
| 26 | Allow `upload-pack` to accept a fetch request that asks for any |
| 27 | object at all. |
| 28 | It implies `uploadpack.allowTipSHA1InWant` and |
| 29 | `uploadpack.allowReachableSHA1InWant`. If set to `true` it will |
| 30 | enable both of them, it set to `false` it will disable both of |
| 31 | them. |
| 32 | By default not set. |
| 33 | |
| 34 | uploadpack.keepAlive:: |
| 35 | When `upload-pack` has started `pack-objects`, there may be a |
| 36 | quiet period while `pack-objects` prepares the pack. Normally |
| 37 | it would output progress information, but if `--quiet` was used |
| 38 | for the fetch, `pack-objects` will output nothing at all until |
| 39 | the pack data begins. Some clients and networks may consider |
| 40 | the server to be hung and give up. Setting this option instructs |
| 41 | `upload-pack` to send an empty keepalive packet every |
| 42 | `uploadpack.keepAlive` seconds. Setting this option to 0 |
| 43 | disables keepalive packets entirely. The default is 5 seconds. |
| 44 | |
| 45 | uploadpack.packObjectsHook:: |
| 46 | If this option is set, when `upload-pack` would run |
| 47 | `git pack-objects` to create a packfile for a client, it will |
| 48 | run this shell command instead. The `pack-objects` command and |
| 49 | arguments it _would_ have run (including the `git pack-objects` |
| 50 | at the beginning) are appended to the shell command. The stdin |
| 51 | and stdout of the hook are treated as if `pack-objects` itself |
| 52 | was run. I.e., `upload-pack` will feed input intended for |
| 53 | `pack-objects` to the hook, and expects a completed packfile on |
| 54 | stdout. |
| 55 | + |
| 56 | Note that this configuration variable is only respected when it is specified |
| 57 | in protected configuration (see <<SCOPES>>). This is a safety measure |
| 58 | against fetching from untrusted repositories. |
| 59 | |
| 60 | uploadpack.allowFilter:: |
| 61 | If this option is set, `upload-pack` will support partial |
| 62 | clone and partial fetch object filtering. |
| 63 | |
| 64 | uploadpackfilter.allow:: |
| 65 | Provides a default value for unspecified object filters (see: the |
| 66 | below configuration variable). If set to `true`, this will also |
| 67 | enable all filters which get added in the future. |
| 68 | Defaults to `true`. |
| 69 | |
| 70 | uploadpackfilter.<filter>.allow:: |
| 71 | Explicitly allow or ban the object filter corresponding to |
| 72 | `<filter>`, where `<filter>` may be one of: `blob:none`, |
| 73 | `blob:limit`, `object:type`, `tree`, `sparse:oid`, or `combine`. |
| 74 | If using combined filters, both `combine` and all of the nested |
| 75 | filter kinds must be allowed. Defaults to `uploadpackfilter.allow`. |
| 76 | |
| 77 | uploadpackfilter.tree.maxDepth:: |
| 78 | Only allow `--filter=tree:<n>` when `<n>` is no more than the value of |
| 79 | `uploadpackfilter.tree.maxDepth`. If set, this also implies |
| 80 | `uploadpackfilter.tree.allow=true`, unless this configuration |
| 81 | variable had already been set. Has no effect if unset. |
| 82 | |
| 83 | uploadpack.allowRefInWant:: |
| 84 | If this option is set, `upload-pack` will support the `ref-in-want` |
| 85 | feature of the protocol version 2 `fetch` command. This feature |
| 86 | is intended for the benefit of load-balanced servers which may |
| 87 | not have the same view of what OIDs their refs point to due to |
| 88 | replication delay. |