git.oblomov.eu Git - git/blob - 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.procReceiveRefs::
 118         This is a multi-valued variable that defines reference prefixes
 119         to match the commands in `receive-pack`.  Commands matching the
 120         prefixes will be executed by an external hook "proc-receive",
 121         instead of the internal `execute_commands` function.  If this
 122         variable is not defined, the "proc-receive" hook will never be
 123         used, and all commands will be executed by the internal
 124         `execute_commands` function.
 125 +
 126 For example, if this variable is set to "refs/for", pushing to reference
 127 such as "refs/for/master" will not create or update a reference named
 128 "refs/for/master", but may create or update a pull request directly by
 129 running the hook "proc-receive".
 130 +
 131 Optional modifiers can be provided in the beginning of the value to filter
 132 commands for specific actions: create (a), modify (m), delete (d).
 133 A `!` can be included in the modifiers to negate the reference prefix entry.
 134 E.g.:
 135 +
 136         git config --system --add receive.procReceiveRefs ad:refs/heads
 137         git config --system --add receive.procReceiveRefs !:refs/heads
 138
 139 receive.updateServerInfo::
 140         If set to true, git-receive-pack will run git-update-server-info
 141         after receiving data from git-push and updating refs.
 142
 143 receive.shallowUpdate::
 144         If set to true, .git/shallow can be updated when new refs
 145         require new shallow roots. Otherwise those refs are rejected.