240 lines
8.8 KiB
Markdown
240 lines
8.8 KiB
Markdown
git-lfs-config(5) -- Configuration options for git-lfs
|
|
======================================================
|
|
|
|
## CONFIGURATION FILES
|
|
|
|
git-lfs uses the same configuration files as git-config(1) with the same
|
|
precedence. Most options pertaining to git-lfs are contained in the `[lfs]`
|
|
section, meaning they all named `lfs.foo` or similar, although occasionally an
|
|
lfs option can be scoped inside the configuration for a remote.
|
|
|
|
## LIST OF OPTIONS
|
|
|
|
### General settings
|
|
|
|
* `lfs.url` / `<remote>.lfsurl`
|
|
|
|
The url used to call the Git LFS remote API. Default blank (derive from clone
|
|
URL).
|
|
|
|
* `lfs.pushurl` / `<remote>.lfspushurl`
|
|
|
|
The url used to call the Git LFS remote API when pushing. Default blank (derive
|
|
from either LFS non-push urls or clone url).
|
|
|
|
* `lfs.batch`
|
|
|
|
Whether to use the batch API instead of requesting objects individually.
|
|
Default true. This setting transitions clients from the legacy to the newer
|
|
batch API and will be gone in Git LFS v1.0.
|
|
|
|
* `lfs.dialtimeout`
|
|
|
|
Sets the maximum time, in seconds, that the HTTP client will wait initiate a
|
|
connection. This does not include the time to send a request and wait for a
|
|
response. Default: 30 seconds
|
|
|
|
* `lfs.tlstimeout`
|
|
|
|
Sets the maximum time, in seconds, that the HTTP client will wait for a TLS
|
|
handshake. Default: 30 seconds.
|
|
|
|
* `lfs.keepalive`
|
|
|
|
Sets the maximum time, in seconds, for the HTTP client to maintain keepalive
|
|
connections. Default: 30 minutes.
|
|
|
|
### Transfer (upload / download) settings
|
|
|
|
These settings control how the upload and download of LFS content occurs.
|
|
|
|
* `lfs.concurrenttransfers`
|
|
|
|
The number of concurrent uploads/downloads. Default 3.
|
|
|
|
* `lfs.basictransfersonly`
|
|
|
|
If set to true, only basic HTTP upload/download transfers will be used,
|
|
ignoring any more advanced transfers that the client/server may support.
|
|
This is primarily to work around bugs or incompatibilities.
|
|
|
|
The git-lfs client supports basic HTTP downloads, resumable HTTP downloads
|
|
(using `Range` headers), and resumable uploads via tus.io protocol. Custom
|
|
transfer methods can be added via `lfs.customtransfer` (see next section).
|
|
However setting this value to true limits the client to simple HTTP.
|
|
|
|
* `lfs.tustransfers`
|
|
|
|
If set to true, this enables resumable uploads of LFS objects through the
|
|
tus.io API. Once this feature is finalized, this setting will be removed,
|
|
and tus.io uploads will be available for all clients.
|
|
|
|
* `lfs.customtransfer.<name>.path`
|
|
|
|
`lfs.customtransfer.<name>` is a settings group which defines a custom
|
|
transfer hook which allows you to upload/download via an intermediate process,
|
|
using any mechanism you like (rather than just HTTP). `path` should point to
|
|
the process you wish to invoke. The protocol between the git-lfs client and
|
|
the custom transfer process is documented at
|
|
https://github.com/git-lfs/git-lfs/blob/master/docs/custom-transfers.md
|
|
|
|
<name> must be a unique identifier that the LFS server understands. When
|
|
calling the LFS API the client will include a list of supported transfer
|
|
types. If the server also supports this named transfer type, it will select it
|
|
and actions returned from the API will be in relation to that transfer type
|
|
(may not be traditional URLs for example). Only if the server accepts <name>
|
|
as a transfer it supports will this custom transfer process be invoked.
|
|
|
|
* `lfs.customtransfer.<name>.args`
|
|
|
|
If the custom transfer process requires any arguments, these can be provided
|
|
here.
|
|
|
|
* `lfs.customtransfer.<name>.concurrent`
|
|
|
|
If true (the default), git-lfs will invoke the custom transfer process
|
|
multiple times in parallel, according to `lfs.concurrenttransfers`, splitting
|
|
the transfer workload between the processes.
|
|
|
|
* `lfs.customtransfer.<name>.direction`
|
|
|
|
Specifies which direction the custom transfer process supports, either
|
|
"download", "upload", or "both". The default if unspecified is "both".
|
|
|
|
* `lfs.transfer.maxretries`
|
|
|
|
Specifies how many retries LFS will attempt per OID before marking the
|
|
transfer as failed. Must be an integer which is at least one. If the value is
|
|
not an integer, is less than one, or is not given, a value of one will be used
|
|
instead.
|
|
|
|
### Fetch settings
|
|
|
|
* `lfs.fetchinclude`
|
|
|
|
When fetching, only download objects which match any entry on this
|
|
comma-separated list of paths/filenames. Wildcard matching is as per
|
|
git-ignore(1). See git-lfs-fetch(1) for examples.
|
|
|
|
* `lfs.fetchexclude`
|
|
|
|
When fetching, do not download objects which match any item on this
|
|
comma-separated list of paths/filenames. Wildcard matching is as per
|
|
git-ignore(1). See git-lfs-fetch(1) for examples.
|
|
|
|
|
|
* `lfs.fetchrecentrefsdays`
|
|
|
|
If non-zero, fetches refs which have commits within N days of the current
|
|
date. Only local refs are included unless lfs.fetchrecentremoterefs is true.
|
|
Also used as a basis for pruning old files.
|
|
The default is 7 days.
|
|
|
|
* `lfs.fetchrecentremoterefs`
|
|
|
|
If true, fetches remote refs (for the remote you're fetching) as well as local
|
|
refs in the recent window. This is useful to fetch objects for remote branches
|
|
you might want to check out later. The default is true; if you set this to
|
|
false, fetching for those branches will only occur when you either check them
|
|
out (losing the advantage of fetch --recent), or create a tracking local
|
|
branch separately then fetch again.
|
|
|
|
* `lfs.fetchrecentcommitsdays`
|
|
|
|
In addition to fetching at refs, also fetches previous changes made within N
|
|
days of the latest commit on the ref. This is useful if you're often reviewing
|
|
recent changes. Also used as a basis for pruning old files.
|
|
The default is 0 (no previous changes).
|
|
|
|
* `lfs.fetchrecentalways`
|
|
|
|
Always operate as if --recent was included in a `git lfs fetch` call. Default
|
|
false.
|
|
|
|
### Prune settings
|
|
|
|
* `lfs.pruneoffsetdays`
|
|
|
|
The number of days added to the `lfs.fetchrecent*` settings to determine what
|
|
can be pruned. Default is 3 days, i.e. that anything fetched at the very
|
|
oldest edge of the 'recent window' is eligible for pruning 3 days later.
|
|
|
|
* `lfs.pruneremotetocheck`
|
|
|
|
Set the remote that LFS files must have been pushed to in order for them to
|
|
be considered eligible for local pruning. Also the remote which is called if
|
|
--verify-remote is enabled.
|
|
|
|
* `lfs.pruneverifyremotealways`
|
|
|
|
Always run `git lfs prune` as if `--verify-remote` was provided.
|
|
|
|
### Extensions
|
|
|
|
* `lfs.extension.<name>.<setting>`
|
|
|
|
Git LFS extensions enable the manipulation of files streams during smudge and
|
|
clean. `name` groups the settings for a single extension, and the settings
|
|
are:
|
|
* `clean` The command which runs when files are added to the index
|
|
* `smudge` The command which runs when files are written to the working copy
|
|
* `priority` The order of this extension compared to others
|
|
|
|
### Other settings
|
|
|
|
* `lfs.<url>.access`
|
|
|
|
Note: this setting is normally set by LFS itself on receiving a 401 response
|
|
(authentication required), you don't normally need to set it manually.
|
|
|
|
If set to "basic" then credentials will be requested before making batch
|
|
requests to this url, otherwise a public request will initially be attempted.
|
|
|
|
* `lfs.skipdownloaderrors`
|
|
|
|
Causes Git LFS not to abort the smudge filter when a download error is
|
|
encountered, which allows actions such as checkout to work when you are unable
|
|
to download the LFS content. LFS files which could not download will contain
|
|
pointer content instead.
|
|
|
|
Note that this will result in git commands which call the smudge filter to
|
|
report success even in cases when LFS downloads fail, which may affect
|
|
scripts.
|
|
|
|
You can also set the environment variable GIT_LFS_SKIP_DOWNLOAD_ERRORS=1 to
|
|
get the same effect.
|
|
|
|
* `GIT_LFS_PROGRESS`
|
|
|
|
This environment variable causes Git LFS to emit progress updates to an
|
|
absolute file-path on disk when cleaning, smudging, or fetching.
|
|
|
|
Progress is reported periodically in the form of a new line being appended to
|
|
the end of the file. Each new line will take the following format:
|
|
|
|
`<direction> <current>/<total files> <downloaded>/<total> <name>`
|
|
|
|
Each field is described below:
|
|
* `direction`: The direction of transfer, either "checkout", "download", or
|
|
"upload".
|
|
* `current` The index of the currently transferring file.
|
|
* `total files` The estimated count of all files to be transferred.
|
|
* `downloaded` The number of bytes already downloaded.
|
|
* `total` The entire size of the file, in bytes.
|
|
* `name` The name of the file.
|
|
|
|
* `GIT_LFS_SET_LOCKABLE_READONLY`
|
|
`lfs.setlockablereadonly`
|
|
|
|
These settings, the first an environment variable and the second a gitconfig
|
|
setting, control whether files marked as 'lockable' in `git lfs track` are
|
|
made read-only in the working copy when not locked by the current user.
|
|
The default is `true`; you can disable this behaviour and have all files
|
|
writeable by setting either variable to 0, 'no' or 'false'.
|
|
|
|
## SEE ALSO
|
|
|
|
git-config(1), git-lfs-install(1), gitattributes(5)
|
|
|
|
Part of the git-lfs(1) suite.
|