upload-pack: do not lazy-fetch "have" objects
[git] / Documentation / config / receive.txt
1 receive.advertiseAtomic::
2         By default, git-receive-pack will advertise the atomic push
3         capability to its clients. If you don't want to advertise this
4         capability, set this variable to false.
5
6 receive.advertisePushOptions::
7         When set to true, git-receive-pack will advertise the push options
8         capability to its clients. False by default.
9
10 receive.autogc::
11         By default, git-receive-pack will run "git-gc --auto" after
12         receiving data from git-push and updating refs.  You can stop
13         it by setting this variable to false.
14
15 receive.certNonceSeed::
16         By setting this variable to a string, `git receive-pack`
17         will accept a `git push --signed` and verifies it by using
18         a "nonce" protected by HMAC using this string as a secret
19         key.
20
21 receive.certNonceSlop::
22         When a `git push --signed` sent a push certificate with a
23         "nonce" that was issued by a receive-pack serving the same
24         repository within this many seconds, export the "nonce"
25         found in the certificate to `GIT_PUSH_CERT_NONCE` to the
26         hooks (instead of what the receive-pack asked the sending
27         side to include).  This may allow writing checks in
28         `pre-receive` and `post-receive` a bit easier.  Instead of
29         checking `GIT_PUSH_CERT_NONCE_SLOP` environment variable
30         that records by how many seconds the nonce is stale to
31         decide if they want to accept the certificate, they only
32         can check `GIT_PUSH_CERT_NONCE_STATUS` is `OK`.
33
34 receive.fsckObjects::
35         If it is set to true, git-receive-pack will check all received
36         objects. See `transfer.fsckObjects` for what's checked.
37         Defaults to false. If not set, the value of
38         `transfer.fsckObjects` is used instead.
39
40 receive.fsck.<msg-id>::
41         Acts like `fsck.<msg-id>`, but is used by
42         linkgit:git-receive-pack[1] instead of
43         linkgit:git-fsck[1]. See the `fsck.<msg-id>` documentation for
44         details.
45
46 receive.fsck.skipList::
47         Acts like `fsck.skipList`, but is used by
48         linkgit:git-receive-pack[1] instead of
49         linkgit:git-fsck[1]. See the `fsck.skipList` documentation for
50         details.
51
52 receive.keepAlive::
53         After receiving the pack from the client, `receive-pack` may
54         produce no output (if `--quiet` was specified) while processing
55         the pack, causing some networks to drop the TCP connection.
56         With this option set, if `receive-pack` does not transmit
57         any data in this phase for `receive.keepAlive` seconds, it will
58         send a short keepalive packet.  The default is 5 seconds; set
59         to 0 to disable keepalives entirely.
60
61 receive.unpackLimit::
62         If the number of objects received in a push is below this
63         limit then the objects will be unpacked into loose object
64         files. However if the number of received objects equals or
65         exceeds this limit then the received pack will be stored as
66         a pack, after adding any missing delta bases.  Storing the
67         pack from a push can make the push operation complete faster,
68         especially on slow filesystems.  If not set, the value of
69         `transfer.unpackLimit` is used instead.
70
71 receive.maxInputSize::
72         If the size of the incoming pack stream is larger than this
73         limit, then git-receive-pack will error out, instead of
74         accepting the pack file. If not set or set to 0, then the size
75         is unlimited.
76
77 receive.denyDeletes::
78         If set to true, git-receive-pack will deny a ref update that deletes
79         the ref. Use this to prevent such a ref deletion via a push.
80
81 receive.denyDeleteCurrent::
82         If set to true, git-receive-pack will deny a ref update that
83         deletes the currently checked out branch of a non-bare repository.
84
85 receive.denyCurrentBranch::
86         If set to true or "refuse", git-receive-pack will deny a ref update
87         to the currently checked out branch of a non-bare repository.
88         Such a push is potentially dangerous because it brings the HEAD
89         out of sync with the index and working tree. If set to "warn",
90         print a warning of such a push to stderr, but allow the push to
91         proceed. If set to false or "ignore", allow such pushes with no
92         message. Defaults to "refuse".
93 +
94 Another option is "updateInstead" which will update the working
95 tree if pushing into the current branch.  This option is
96 intended for synchronizing working directories when one side is not easily
97 accessible via interactive ssh (e.g. a live web site, hence the requirement
98 that the working directory be clean). This mode also comes in handy when
99 developing inside a VM to test and fix code on different Operating Systems.
100 +
101 By default, "updateInstead" will refuse the push if the working tree or
102 the index have any difference from the HEAD, but the `push-to-checkout`
103 hook can be used to customize this.  See linkgit:githooks[5].
104
105 receive.denyNonFastForwards::
106         If set to true, git-receive-pack will deny a ref update which is
107         not a fast-forward. Use this to prevent such an update via a push,
108         even if that push is forced. This configuration variable is
109         set when initializing a shared repository.
110
111 receive.hideRefs::
112         This variable is the same as `transfer.hideRefs`, but applies
113         only to `receive-pack` (and so affects pushes, but not fetches).
114         An attempt to update or delete a hidden ref by `git push` is
115         rejected.
116
117 receive.updateServerInfo::
118         If set to true, git-receive-pack will run git-update-server-info
119         after receiving data from git-push and updating refs.
120
121 receive.shallowUpdate::
122         If set to true, .git/shallow can be updated when new refs
123         require new shallow roots. Otherwise those refs are rejected.