git-lfs-config.5.ronn

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/github/git-lfs/blob/master/docs/custom-transfers.md

  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 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".

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.

SEE ALSO

git-config(1), git-lfs-install(1), gitattributes(5)

Part of the git-lfs(1) suite.