github.com/stffabi/git-lfs@v2.3.5-0.20180214015214-8eeaa8d88902+incompatible/docs/man/git-lfs-config.5.ronn (about) 1 git-lfs-config(5) -- Configuration options for git-lfs 2 ====================================================== 3 4 ## CONFIGURATION FILES 5 6 git-lfs reads its configuration from a file called `.lfsconfig` at the root of 7 the repository. The `.lfsconfig` file uses the same format as `.gitconfig`. 8 9 Additionally, all settings can be overridden by values returned by `git config -l`. 10 This allows you to override settings like `lfs.url` in your local environment 11 without having to modify the `.lfsconfig` file. 12 13 Most options regarding git-lfs are contained in the `[lfs]` section, meaning 14 they are all named `lfs.foo` or similar, although occasionally an lfs option can 15 be scoped inside the configuration for a remote. 16 17 18 ## LIST OF OPTIONS 19 20 ### General settings 21 22 * `lfs.url` / `remote.<remote>.lfsurl` 23 24 The url used to call the Git LFS remote API. Default blank (derive from clone 25 URL). 26 27 * `lfs.pushurl` / `remote.<remote>.lfspushurl` 28 29 The url used to call the Git LFS remote API when pushing. Default blank (derive 30 from either LFS non-push urls or clone url). 31 32 * `lfs.dialtimeout` 33 34 Sets the maximum time, in seconds, that the HTTP client will wait to initiate 35 a connection. This does not include the time to send a request and wait for a 36 response. Default: 30 seconds 37 38 * `lfs.tlstimeout` 39 40 Sets the maximum time, in seconds, that the HTTP client will wait for a TLS 41 handshake. Default: 30 seconds. 42 43 * `lfs.activitytimeout` / `lfs.https://<host>.activitytimeout` 44 45 Sets the maximum time, in seconds, that the HTTP client will wait for the 46 next tcp read or write. If < 1, no activity timeout is used at all. 47 Default: 30 seconds 48 49 * `lfs.keepalive` 50 51 Sets the maximum time, in seconds, for the HTTP client to maintain keepalive 52 connections. Default: 30 minutes. 53 54 * `core.askpass`, GIT_ASKPASS 55 56 Given as a program and its arguments, this is invoked when authentication is 57 needed against the LFS API. The contents of stdout are interpreted as the 58 password. 59 60 * `lfs.cachecredentials` 61 62 Enables in-memory SSH and Git Credential caching for a single 'git lfs' 63 command. Default: enabled. 64 65 * `lfs.storage` 66 67 Allow override LFS storage directory. Non-absolute path is relativized to 68 inside of Git repository directory (usually `.git`). 69 70 Note: you should not run `git lfs prune` if you have different repositories 71 sharing the same storage directory. 72 73 Default: `lfs` in Git repository directory (usually `.git/lfs`). 74 75 ### Transfer (upload / download) settings 76 77 These settings control how the upload and download of LFS content occurs. 78 79 * `lfs.concurrenttransfers` 80 81 The number of concurrent uploads/downloads. Default 8. 82 83 * `lfs.basictransfersonly` 84 85 If set to true, only basic HTTP upload/download transfers will be used, 86 ignoring any more advanced transfers that the client/server may support. 87 This is primarily to work around bugs or incompatibilities. 88 89 The git-lfs client supports basic HTTP downloads, resumable HTTP downloads 90 (using `Range` headers), and resumable uploads via tus.io protocol. Custom 91 transfer methods can be added via `lfs.customtransfer` (see next section). 92 However setting this value to true limits the client to simple HTTP. 93 94 * `lfs.tustransfers` 95 96 If set to true, this enables resumable uploads of LFS objects through the 97 tus.io API. Once this feature is finalized, this setting will be removed, 98 and tus.io uploads will be available for all clients. 99 100 * `lfs.standalonetransferagent` 101 102 Allows the specified custom transfer agent to be used directly 103 for transferring files, without asking the server how the transfers 104 should be made. The custom transfer agent has to be defined in a 105 `lfs.customtransfer.<name>` settings group. 106 107 * `lfs.customtransfer.<name>.path` 108 109 `lfs.customtransfer.<name>` is a settings group which defines a custom 110 transfer hook which allows you to upload/download via an intermediate process, 111 using any mechanism you like (rather than just HTTP). `path` should point to 112 the process you wish to invoke. The protocol between the git-lfs client and 113 the custom transfer process is documented at 114 https://github.com/git-lfs/git-lfs/blob/master/docs/custom-transfers.md 115 116 <name> must be a unique identifier that the LFS server understands. When 117 calling the LFS API the client will include a list of supported transfer 118 types. If the server also supports this named transfer type, it will select it 119 and actions returned from the API will be in relation to that transfer type 120 (may not be traditional URLs for example). Only if the server accepts <name> 121 as a transfer it supports will this custom transfer process be invoked. 122 123 * `lfs.customtransfer.<name>.args` 124 125 If the custom transfer process requires any arguments, these can be provided 126 here. 127 128 * `lfs.customtransfer.<name>.concurrent` 129 130 If true (the default), git-lfs will invoke the custom transfer process 131 multiple times in parallel, according to `lfs.concurrenttransfers`, splitting 132 the transfer workload between the processes. 133 134 * `lfs.customtransfer.<name>.direction` 135 136 Specifies which direction the custom transfer process supports, either 137 "download", "upload", or "both". The default if unspecified is "both". 138 139 * `lfs.transfer.maxretries` 140 141 Specifies how many retries LFS will attempt per OID before marking the 142 transfer as failed. Must be an integer which is at least one. If the value is 143 not an integer, is less than one, or is not given, a value of eight will be 144 used instead. 145 146 * `lfs.transfer.maxverifies` 147 148 Specifies how many verification requests LFS will attempt per OID before 149 marking the transfer as failed, if the object has a verification action 150 associated with it. Must be an integer which is at least one. If the value is 151 not an integer, is less than one, or is not given, a default value of three 152 will be used instead. 153 154 ### Push settings 155 156 * `lfs.allowincompletepush` 157 158 When pushing, allow objects to be missing from the local cache without halting 159 a Git push. Default: true. 160 161 ### Fetch settings 162 163 * `lfs.fetchinclude` 164 165 When fetching, only download objects which match any entry on this 166 comma-separated list of paths/filenames. Wildcard matching is as per 167 git-ignore(1). See git-lfs-fetch(1) for examples. 168 169 * `lfs.fetchexclude` 170 171 When fetching, do not download objects which match any item on this 172 comma-separated list of paths/filenames. Wildcard matching is as per 173 git-ignore(1). See git-lfs-fetch(1) for examples. 174 175 * `lfs.fetchrecentrefsdays` 176 177 If non-zero, fetches refs which have commits within N days of the current 178 date. Only local refs are included unless lfs.fetchrecentremoterefs is true. 179 Also used as a basis for pruning old files. 180 The default is 7 days. 181 182 * `lfs.fetchrecentremoterefs` 183 184 If true, fetches remote refs (for the remote you're fetching) as well as local 185 refs in the recent window. This is useful to fetch objects for remote branches 186 you might want to check out later. The default is true; if you set this to 187 false, fetching for those branches will only occur when you either check them 188 out (losing the advantage of fetch --recent), or create a tracking local 189 branch separately then fetch again. 190 191 * `lfs.fetchrecentcommitsdays` 192 193 In addition to fetching at refs, also fetches previous changes made within N 194 days of the latest commit on the ref. This is useful if you're often reviewing 195 recent changes. Also used as a basis for pruning old files. 196 The default is 0 (no previous changes). 197 198 * `lfs.fetchrecentalways` 199 200 Always operate as if --recent was included in a `git lfs fetch` call. Default 201 false. 202 203 ### Prune settings 204 205 * `lfs.pruneoffsetdays` 206 207 The number of days added to the `lfs.fetchrecent*` settings to determine what 208 can be pruned. Default is 3 days, i.e. that anything fetched at the very 209 oldest edge of the 'recent window' is eligible for pruning 3 days later. 210 211 * `lfs.pruneremotetocheck` 212 213 Set the remote that LFS files must have been pushed to in order for them to 214 be considered eligible for local pruning. Also the remote which is called if 215 --verify-remote is enabled. 216 217 * `lfs.pruneverifyremotealways` 218 219 Always run `git lfs prune` as if `--verify-remote` was provided. 220 221 ### Extensions 222 223 * `lfs.extension.<name>.<setting>` 224 225 Git LFS extensions enable the manipulation of files streams during smudge and 226 clean. `name` groups the settings for a single extension, and the settings 227 are: 228 * `clean` The command which runs when files are added to the index 229 * `smudge` The command which runs when files are written to the working copy 230 * `priority` The order of this extension compared to others 231 232 ### Other settings 233 234 * `lfs.<url>.access` 235 236 Note: this setting is normally set by LFS itself on receiving a 401 response 237 (authentication required), you don't normally need to set it manually. 238 239 If set to "basic" then credentials will be requested before making batch 240 requests to this url, otherwise a public request will initially be attempted. 241 242 * `lfs.<url>.locksverify` 243 244 Determines whether locks are checked before Git pushes. This prevents you from 245 pushing changes to files that other users have locked. The Git LFS pre-push 246 hook varies its behavior based on the value of this config key. 247 248 * `null` - In the absence of a value, Git LFS will attempt the call, and warn 249 if it returns an error. If the response is valid, Git LFS will set the value 250 to `true`, and will halt the push if the user attempts to update a file locked 251 by another user. If the server returns a `501 Not Implemented` response, Git 252 LFS will set the value to `false.` 253 * `true` - Git LFS will attempt to verify locks, halting the Git push if there 254 are any server issues, or if the user attempts to update a file locked by 255 another user. 256 * `false` - Git LFS will completely skip the lock check in the pre-push hook. 257 You should set this if you're not using File Locking, or your Git server 258 verifies locked files on pushes automatically. 259 260 Supports URL config lookup as described in: 261 https://git-scm.com/docs/git-config#git-config-httplturlgt. To set this value 262 per-host: `git config --global lfs.https://github.com/.locksverify [true|false]`. 263 264 * `lfs.skipdownloaderrors` 265 266 Causes Git LFS not to abort the smudge filter when a download error is 267 encountered, which allows actions such as checkout to work when you are unable 268 to download the LFS content. LFS files which could not download will contain 269 pointer content instead. 270 271 Note that this will result in git commands which call the smudge filter to 272 report success even in cases when LFS downloads fail, which may affect 273 scripts. 274 275 You can also set the environment variable GIT_LFS_SKIP_DOWNLOAD_ERRORS=1 to 276 get the same effect. 277 278 * `GIT_LFS_PROGRESS` 279 280 This environment variable causes Git LFS to emit progress updates to an 281 absolute file-path on disk when cleaning, smudging, or fetching. 282 283 Progress is reported periodically in the form of a new line being appended to 284 the end of the file. Each new line will take the following format: 285 286 `<direction> <current>/<total files> <downloaded>/<total> <name>` 287 288 Each field is described below: 289 * `direction`: The direction of transfer, either "checkout", "download", or 290 "upload". 291 * `current` The index of the currently transferring file. 292 * `total files` The estimated count of all files to be transferred. 293 * `downloaded` The number of bytes already downloaded. 294 * `total` The entire size of the file, in bytes. 295 * `name` The name of the file. 296 297 * `GIT_LFS_SET_LOCKABLE_READONLY` 298 `lfs.setlockablereadonly` 299 300 These settings, the first an environment variable and the second a gitconfig 301 setting, control whether files marked as 'lockable' in `git lfs track` are 302 made read-only in the working copy when not locked by the current user. 303 The default is `true`; you can disable this behaviour and have all files 304 writeable by setting either variable to 0, 'no' or 'false'. 305 306 ## LFSCONFIG 307 308 The .lfsconfig file in a repository is read and interpreted in the same format 309 as the file stored in .git/config. It allows a subset of keys to be used, 310 including and limited to: 311 312 - lfs.fetchexclude 313 - lfs.fetchinclude 314 - lfs.gitprotocol 315 - lfs.pushurl 316 - lfs.url 317 - lfs.extension.{name}.clean 318 - lfs.extension.{name}.smudge 319 - lfs.extension.{name}.priority 320 - remote.{name}.lfsurl 321 - remote.{name}.{*}.access 322 323 ## EXAMPLES 324 325 * Configure a custom LFS endpoint for your repository: 326 327 `git config -f .lfsconfig lfs.url https://lfs.example.com/foo/bar/info/lfs` 328 329 ## SEE ALSO 330 331 git-config(1), git-lfs-install(1), gitattributes(5) 332 333 Part of the git-lfs(1) suite.