github.com/psexton/git-lfs@v2.1.1-0.20170517224304-289a18b2bc53+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: 10 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  * `lfs.cachecredentials`
    55  
    56    Enables in-memory SSH and Git Credential caching for a single 'git lfs'
    57    command. Default: false. This will default to true in v2.1.0.
    58  
    59  ### Transfer (upload / download) settings
    60  
    61    These settings control how the upload and download of LFS content occurs.
    62  
    63  * `lfs.concurrenttransfers`
    64  
    65    The number of concurrent uploads/downloads. Default 3.
    66  
    67  * `lfs.basictransfersonly`
    68  
    69    If set to true, only basic HTTP upload/download transfers will be used,
    70    ignoring any more advanced transfers that the client/server may support.
    71    This is primarily to work around bugs or incompatibilities.
    72  
    73    The git-lfs client supports basic HTTP downloads, resumable HTTP downloads
    74    (using `Range` headers), and resumable uploads via tus.io protocol. Custom
    75    transfer methods can be added via `lfs.customtransfer` (see next section).
    76    However setting this value to true limits the client to simple HTTP.
    77  
    78  * `lfs.tustransfers`
    79  
    80    If set to true, this enables resumable uploads of LFS objects through the
    81    tus.io API. Once this feature is finalized, this setting will be removed,
    82    and tus.io uploads will be available for all clients.
    83  
    84  * `lfs.customtransfer.<name>.path`
    85  
    86    `lfs.customtransfer.<name>` is a settings group which defines a custom
    87    transfer hook which allows you to upload/download via an intermediate process,
    88    using any mechanism you like (rather than just HTTP). `path` should point to
    89    the process you wish to invoke. The protocol between the git-lfs client and
    90    the custom transfer process is documented at
    91    https://github.com/git-lfs/git-lfs/blob/master/docs/custom-transfers.md
    92  
    93    <name> must be a unique identifier that the LFS server understands. When
    94    calling the LFS API the client will include a list of supported transfer
    95    types. If the server also supports this named transfer type, it will select it
    96    and actions returned from the API will be in relation to that transfer type
    97    (may not be traditional URLs for example). Only if the server accepts <name>
    98    as a transfer it supports will this custom transfer process be invoked.
    99  
   100  * `lfs.customtransfer.<name>.args`
   101  
   102    If the custom transfer process requires any arguments, these can be provided
   103    here.
   104  
   105  * `lfs.customtransfer.<name>.concurrent`
   106  
   107    If true (the default), git-lfs will invoke the custom transfer process
   108    multiple times in parallel, according to `lfs.concurrenttransfers`, splitting
   109    the transfer workload between the processes.
   110  
   111  * `lfs.customtransfer.<name>.direction`
   112  
   113    Specifies which direction the custom transfer process supports, either
   114    "download", "upload", or "both". The default if unspecified is "both".
   115  
   116  * `lfs.transfer.maxretries`
   117  
   118    Specifies how many retries LFS will attempt per OID before marking the
   119    transfer as failed. Must be an integer which is at least one. If the value is
   120    not an integer, is less than one, or is not given, a value of eight will be
   121    used instead.
   122  
   123  * `lfs.transfer.maxverifies`
   124  
   125    Specifies how many verification requests LFS will attempt per OID before
   126    marking the transfer as failed, if the object has a verification action
   127    associated with it. Must be an integer which is at least one. If the value is
   128    not an integer, is less than one, or is not given, a default value of three
   129    will be used instead.
   130  
   131  ### Push settings
   132  
   133  * `lfs.allowincompletepush`
   134  
   135    When pushing, allow objects to be missing from the local cache without halting
   136    a Git push.
   137  
   138  ### Fetch settings
   139  
   140  * `lfs.fetchinclude`
   141  
   142    When fetching, only download objects which match any entry on this
   143    comma-separated list of paths/filenames. Wildcard matching is as per
   144    git-ignore(1). See git-lfs-fetch(1) for examples.
   145  
   146  * `lfs.fetchexclude`
   147  
   148    When fetching, do not download objects which match any item on this
   149    comma-separated list of paths/filenames. Wildcard matching is as per
   150    git-ignore(1). See git-lfs-fetch(1) for examples.
   151  
   152  * `lfs.fetchrecentrefsdays`
   153  
   154    If non-zero, fetches refs which have commits within N days of the current
   155    date. Only local refs are included unless lfs.fetchrecentremoterefs is true.
   156    Also used as a basis for pruning old files.
   157    The default is 7 days.
   158  
   159  * `lfs.fetchrecentremoterefs`
   160  
   161    If true, fetches remote refs (for the remote you're fetching) as well as local
   162    refs in the recent window. This is useful to fetch objects for remote branches
   163    you might want to check out later. The default is true; if you set this to
   164    false, fetching for those branches will only occur when you either check them
   165    out (losing the advantage of fetch --recent), or create a tracking local
   166    branch separately then fetch again.
   167  
   168  * `lfs.fetchrecentcommitsdays`
   169  
   170    In addition to fetching at refs, also fetches previous changes made within N
   171    days of the latest commit on the ref. This is useful if you're often reviewing
   172    recent changes.   Also used as a basis for pruning old files.
   173    The default is 0 (no previous changes).
   174  
   175  * `lfs.fetchrecentalways`
   176  
   177    Always operate as if --recent was included in a `git lfs fetch` call. Default
   178    false.
   179  
   180  ### Prune settings
   181  
   182  * `lfs.pruneoffsetdays`
   183  
   184    The number of days added to the `lfs.fetchrecent*` settings to determine what
   185    can be pruned. Default is 3 days, i.e. that anything fetched at the very
   186    oldest edge of the 'recent window' is eligible for pruning 3 days later.
   187  
   188  * `lfs.pruneremotetocheck`
   189  
   190    Set the remote that LFS files must have been pushed to in order for them to
   191    be considered eligible for local pruning. Also the remote which is called if
   192    --verify-remote is enabled.
   193  
   194  * `lfs.pruneverifyremotealways`
   195  
   196    Always run `git lfs prune` as if `--verify-remote` was provided.
   197  
   198  ### Extensions
   199  
   200  * `lfs.extension.<name>.<setting>`
   201  
   202    Git LFS extensions enable the manipulation of files streams during smudge and
   203    clean. `name` groups the settings for a single extension, and the settings
   204    are:
   205    * `clean` The command which runs when files are added to the index
   206    * `smudge` The command which runs when files are written to the working copy
   207    * `priority` The order of this extension compared to others
   208  
   209  ### Other settings
   210  
   211  * `lfs.<url>.access`
   212  
   213    Note: this setting is normally set by LFS itself on receiving a 401 response
   214    (authentication required), you don't normally need to set it manually.
   215  
   216    If set to "basic" then credentials will be requested before making batch
   217    requests to this url, otherwise a public request will initially be attempted.
   218  
   219  * `lfs.<url>.locksverify`
   220  
   221    Determines whether locks are checked before Git pushes. This prevents you from
   222    pushing changes to files that other users have locked. The Git LFS pre-push
   223    hook varies its behavior based on the value of this config key.
   224  
   225    * `null` - In the absence of a value, Git LFS will attempt the call, and warn
   226    if it returns an error. If the response is valid, Git LFS will set the value
   227    to `true`, and will halt the push if the user attempts to update a file locked
   228    by another user. If the server returns a `501 Not Implemented` response, Git
   229    LFS will set the value to `false.`
   230    * `true` - Git LFS will attempt to verify locks, halting the Git push if there
   231    are any server issues, or if the user attempts to update a file locked by
   232    another user.
   233    * `false` - Git LFS will completely skip the lock check in the pre-push hook.
   234    You should set this if you're not using File Locking, or your Git server
   235    verifies locked files on pushes automatically.
   236  
   237    Supports URL config lookup as described in:
   238    https://git-scm.com/docs/git-config#git-config-httplturlgt. To set this value
   239    per-host: `git config lfs.https://github.com/.locksverify 0`.
   240  
   241  * `lfs.skipdownloaderrors`
   242  
   243    Causes Git LFS not to abort the smudge filter when a download error is
   244    encountered, which allows actions such as checkout to work when you are unable
   245    to download the LFS content. LFS files which could not download will contain
   246    pointer content instead.
   247  
   248    Note that this will result in git commands which call the smudge filter to
   249    report success even in cases when LFS downloads fail, which may affect
   250    scripts.
   251  
   252    You can also set the environment variable GIT_LFS_SKIP_DOWNLOAD_ERRORS=1 to
   253    get the same effect.
   254  
   255  * `GIT_LFS_PROGRESS`
   256  
   257    This environment variable causes Git LFS to emit progress updates to an
   258    absolute file-path on disk when cleaning, smudging, or fetching.
   259  
   260    Progress is reported periodically in the form of a new line being appended to
   261    the end of the file. Each new line will take the following format:
   262  
   263    `<direction> <current>/<total files> <downloaded>/<total> <name>`
   264  
   265    Each field is described below:
   266    * `direction`: The direction of transfer, either "checkout", "download", or
   267      "upload".
   268    * `current` The index of the currently transferring file.
   269    * `total files` The estimated count of all files to be transferred.
   270    * `downloaded` The number of bytes already downloaded.
   271    * `total` The entire size of the file, in bytes.
   272    * `name` The name of the file.
   273  
   274  * `GIT_LFS_SET_LOCKABLE_READONLY`
   275    `lfs.setlockablereadonly`
   276  
   277    These settings, the first an environment variable and the second a gitconfig
   278    setting, control whether files marked as 'lockable' in `git lfs track` are
   279    made read-only in the working copy when not locked by the current user.
   280    The default is `true`; you can disable this behaviour and have all files
   281    writeable by setting either variable to 0, 'no' or 'false'.
   282  
   283  ## EXAMPLES
   284  
   285  *  Configure a custom LFS endpoint for your repository:
   286  
   287    `git config -f .lfsconfig lfs.url https://lfs.example.com/foo/bar/info/lfs`
   288  
   289  ## SEE ALSO
   290  
   291  git-config(1), git-lfs-install(1), gitattributes(5)
   292  
   293  Part of the git-lfs(1) suite.