+ git-lfs-checkout - Update working copy with file content if available
+
git lfs checkout filespec...
+git lfs checkout --to path { --ours | --theirs | --base } file...
Try to ensure that the working copy contains file content for Git LFS objects +for the current ref, if the object data is available. Does not download any +content, see git-lfs-fetch(1) for that.
+ +Checkout scans the current ref for all LFS objects that would be required, then +where a file is either missing in the working copy, or contains placeholder +pointer content with the same SHA, the real file content is written, provided +we have it in the local store. Modified files are never overwritten.
+ +Filespecs can be provided as arguments to restrict the files which are updated.
+ +When used with --to and the working tree is in a conflicted state due to a
+merge, this option checks out one of the three stages of the conflict into a
+separate file. This can make using diff tools to inspect and resolve merges
+easier.
--baseCheck out the merge base of the specified file.
--oursCheck out our side (that of the current branch) of the conflict for the +specified file.
--theirsCheck out their side (that of the other branch) of the conflict for the +specified file.
--to pathIf the working tree is in a conflicted state, check out the portion of the
+conflict specified by --base, --ours, or --theirs to the given path.
Checkout all files that are missing or placeholders
+ +git lfs checkout
Checkout a specific couple of files
+ +git lfs checkout path/to/file1.png path/to.file2.png
git-lfs-fetch(1), git-lfs-pull(1).
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-clean - Git clean filter that converts large files to pointers
+
git lfs clean path
Read the contents of a large file from standard input, and write a Git +LFS pointer file for that file to standard output.
+ +Clean is typically run by Git's clean filter, configured by the repository's +Git attributes.
+ +Clean is not part of the user-facing Git plumbing commands. To preview the +pointer of a large file as it would be generated, see the git-lfs-pointer(1) +command.
+ +git-lfs-install(1), git-lfs-push(1), git-lfs-pointer(1), gitattributes(5).
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-clone - Efficiently clone a LFS-enabled repository
+
git lfs clone [git clone options] repository [directory]
Clone an LFS enabled Git repository more efficiently by disabling LFS during the +git clone, then performing a 'git lfs pull' directly afterwards.
+ +'git lfs clone' also installs all of the repo-level hooks (.git/hooks) that LFS
+requires to operate. If --separate-git-dir is given, the hooks will be
+installed there.
This is faster than a regular 'git clone' because that will download LFS content +using the smudge filter, which is executed individually per file in the working +copy. This is relatively inefficient compared to the batch mode and parallel +downloads performed by 'git lfs pull'.
+ +All options supported by 'git clone'
+ +-I paths --include=paths-X paths --exclude=paths--skip-repoSkip installing repo-level hooks (.git/hooks) that LFS requires. Disabled by +default.
You can configure Git LFS to only fetch objects to satisfy references in certain +paths of the repo, and/or to exclude certain paths of the repo, to reduce the +time you spend downloading things you do not use.
+ +In lfsconfig, set lfs.fetchinclude and lfs.fetchexclude to comma-separated lists +of paths to include/exclude in the fetch (wildcard matching as per gitignore). +Only paths which are matched by fetchinclude and not matched by fetchexclude +will have objects fetched for them.
+ +Note that using the command-line options -I and -X override the respective
+configuration settings.
git-clone(1), git-lfs-pull(1).
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-config - Configuration options for git-lfs
+
git-lfs reads its configuration from any file supported by git config -l,
+including all per-repository, per-user, and per-system Git configuration files.
Additionally, a small number of settings can be specified in a file called
+.lfsconfig at the root of the repository; see the "LFSCONFIG" section for more
+details. This configuration file is useful for setting options such as the LFS
+URL or access type for all users of a repository, especially when these differ
+from the default. The .lfsconfig file uses the same format as .gitconfig.
If the .lfsconfig file is missing, the index is checked for a version of the
+file, and that is used instead. If both are missing, HEAD is checked for the
+file. If the repository is bare, only HEAD is checked. This order may change
+for checkouts in the future to better match Git's behavior.
Settings from Git configuration files override the .lfsconfig file. This
+allows you to override settings like lfs.url in your local environment without
+having to modify the .lfsconfig file.
Most options regarding git-lfs are contained in the [lfs] section, meaning
+they are all named lfs.foo or similar, although occasionally an lfs option can
+be scoped inside the configuration for a remote.
lfs.url / remote.<remote>.lfsurl
The url used to call the Git LFS remote API. Default blank (derive from clone +URL).
lfs.pushurl / remote.<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).
remote.lfsdefault
The remote used to find the Git LFS remote API. lfs.url and
+branch.*.remote for the current branch override this setting. If this
+setting is not specified and there is exactly one remote, that remote is
+picked; otherwise, the default is origin.
remote.lfspushdefault
The remote used to find the Git LFS remote API when pushing. lfs.url and
+branch.*.pushremote for the current branch override this setting. If this
+setting is not set, remote.pushdefault is used, or if that is not set, the
+order of selection is used as specified in the remote.lfsdefault above.
lfs.dialtimeout
Sets the maximum time, in seconds, that the HTTP client will wait to 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.activitytimeout / lfs.https://<host>.activitytimeout
Sets the maximum time, in seconds, that the HTTP client will wait for the +next tcp read or write. If < 1, no activity timeout is used at all. +Default: 30 seconds
lfs.keepalive
Sets the maximum time, in seconds, for the HTTP client to maintain keepalive +connections. Default: 30 minutes.
lfs.ssh.automultiplex
When using the pure SSH-based protocol, whether to multiplex requests over a +single connection when possible. This option requires the use of OpenSSH or a +compatible SSH client. Default: true.
lfs.ssh.retries
Specifies the number of times Git LFS will attempt to obtain authorization via +SSH before aborting. Default: 5.
core.askpass, GIT_ASKPASS
Given as a program and its arguments, this is invoked when authentication is +needed against the LFS API. The contents of stdout are interpreted as the +password.
lfs.cachecredentials
Enables in-memory SSH and Git Credential caching for a single 'git lfs' +command. Default: enabled.
lfs.storage
Allow override LFS storage directory. Non-absolute path is relativized to
+inside of Git repository directory (usually .git).
Note: you should not run git lfs prune if you have different repositories
+sharing the same storage directory.
Default: lfs in Git repository directory (usually .git/lfs).
lfs.largefilewarning
Warn when a file is 4 GiB or larger. Such files will be corrupted when using +Windows (unless smudging is disabled) due to a limitation in Git. Default: +true.
These settings control how the upload and download of LFS content occurs.
+ +lfs.concurrenttransfers
The number of concurrent uploads/downloads. Default 8.
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.standalonetransferagent
Allows the specified custom transfer agent to be used directly
+for transferring files, without asking the server how the transfers
+should be made. The custom transfer agent has to be defined in a
+lfs.customtransfer.<name> settings group.
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/main/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. This string will be expanded by the shell.
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 eight will be +used instead.
lfs.transfer.maxretrydelay
Specifies the maximum time in seconds LFS will wait between each retry
+attempt. LFS uses exponential backoff for retries, doubling the time between
+each retry until reaching this limit. If a server requests a delay using the
+Retry-After header, the header value overrides the exponential delay for
+that attempt and is not limited by this option.
Must be an integer which is not negative. Use zero to disable delays between +retries unless requested by a server. If the value is not an integer, is +negative, or is not given, a value of ten will be used instead.
lfs.transfer.maxverifies
Specifies how many verification requests LFS will attempt per OID before +marking the transfer as failed, if the object has a verification action +associated with it. 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 default value of three +will be used instead.
lfs.transfer.enablehrefrewrite
If set to true, this enables rewriting href of LFS objects using
+url.*.insteadof/pushinsteadof config. pushinsteadof is used only for
+uploading, and insteadof is used for downloading and for uploading when
+pushinsteadof is not set.
lfs.allowincompletepush
When pushing, allow objects to be missing from the local cache without halting +a Git push. Default: false.
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.
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.
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 indexsmudge The command which runs when files are written to the working copypriority The order of this extension compared to otherslfs.<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.<url>.locksverify
Determines whether locks are checked before Git pushes. This prevents you from +pushing changes to files that other users have locked. The Git LFS pre-push +hook varies its behavior based on the value of this config key.
+ +null - In the absence of a value, Git LFS will attempt the call, and warn
+if it returns an error. If the response is valid, Git LFS will set the value
+to true, and will halt the push if the user attempts to update a file locked
+by another user. If the server returns a 501 Not Implemented response, Git
+LFS will set the value to false.true - Git LFS will attempt to verify locks, halting the Git push if there
+are any server issues, or if the user attempts to update a file locked by
+another user.false - Git LFS will completely skip the lock check in the pre-push hook.
+You should set this if you're not using File Locking, or your Git server
+verifies locked files on pushes automatically.Supports URL config lookup as described in:
+https://git-scm.com/docs/git-config#git-config-httplturlgt. To set this value
+per-host: git config --global lfs.https://github.com/.locksverify [true|false].
lfs.<url>.contenttype
Determines whether Git LFS should attempt to detect an appropriate HTTP
+Content-Type header when uploading using the 'basic' upload adapter. If set
+to false, the default header of Content-Type: application/octet-stream is
+chosen instead. Default: 'true'.
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_FORCE_PROGRESS
+lfs.forceprogress
Controls whether Git LFS will suppress progress status when the standard
+output stream is not attached to a terminal. The default is false which
+makes Git LFS detect whether stdout is a terminal and suppress progress when
+it's not; you can disable this behaviour and force progress status even when
+standard output stream is not a terminal by setting either variable to 1,
+'yes' or 'true'.
GIT_LFS_SKIP_SMUDGE
Sets whether or not Git LFS will skip attempting to convert pointers of files
+tracked into their corresponding objects when checked out into a working copy.
+If 'true', '1', 'on', or similar, Git LFS will skip the smudge process in both
+git lfs smudge and git lfs filter-process. If unset, or set to 'false',
+'0', 'off', or similar, Git LFS will smudge files as normal.
GIT_LFS_SKIP_PUSH
Sets whether or not Git LFS will attempt to upload new Git LFS object in a +pre-push hook. If 'true', '1', 'on', or similar, Git LFS will skip the +pre-push hook, so no new Git LFS objects will be uploaded. If unset, or set to +'false', '0', 'off', or similar, Git LFS will proceed as normal.
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'.
lfs.lockignoredfiles
This setting controls whether Git LFS will set ignored files that match the
+lockable pattern read only as well as tracked files. The default is false;
+you can enable this behavior by setting the variable to 1, 'yes', or 'true'.
lfs.defaulttokenttl
This setting sets a default token TTL when git-lfs-authenticate does not +include the TTL in the JSON response but still enforces it.
+ +Note that this is only necessary for larger repositories hosted on LFS +servers that don't include the TTL.
The .lfsconfig file in a repository is read and interpreted in the same format +as the file stored in .git/config. It allows a subset of keys to be used, +including and limited to:
+ +The set of keys allowed in this file is restricted for security reasons.
+ + git config -f .lfsconfig lfs.url https://lfs.example.com/foo/bar/info/lfs
git-config(1), git-lfs-install(1), gitattributes(5)
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-env - Display the Git LFS environment
+
git lfs env
Display the current Git LFS environment.
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-ext - View extension details
+
git lfs ext list [name...]
Git LFS extensions enable the manipulation of files streams +during smudge and clean.
+ +List details for all extensions
+ + git lfs ext
+ git lfs ext list
List details for the specified extensions
+ + git lfs ext list 'foo' 'bar'
Part of the git-lfs(1) suite.
+ + +
+ git-lfs-fetch - Download all Git LFS files for a given ref
+
git lfs fetch [options] [remote [ref...]]
Download Git LFS objects at the given refs from the specified remote. See +DEFAULT REMOTE and DEFAULT REFS for what happens if you don't specify.
+ +This does not update the working copy.
+ +-I paths --include=pathsSpecify lfs.fetchinclude just for this invocation; see INCLUDE AND EXCLUDE
-X paths --exclude=pathsSpecify lfs.fetchexclude just for this invocation; see INCLUDE AND EXCLUDE
--recentDownload objects referenced by recent branches & commits in addition to those +that would otherwise be downloaded. See RECENT CHANGES
--allDownload all objects that are referenced by any commit reachable from the refs +provided as arguments. If no refs are provided, then all refs are fetched. +This is primarily for backup and migration purposes. Cannot be combined with +--recent or --include/--exclude. Ignores any globally configured include and +exclude paths to ensure that all objects are downloaded.
--prune -pPrune old and unreferenced objects after fetching, equivalent to running
+git lfs prune afterwards. See git-lfs-prune(1) for more details.
You can configure Git LFS to only fetch objects to satisfy references in certain +paths of the repo, and/or to exclude certain paths of the repo, to reduce the +time you spend downloading things you do not use.
+ +In gitconfig, set lfs.fetchinclude and lfs.fetchexclude to comma-separated
+lists of paths to include/exclude in the fetch. Only paths which are matched by
+fetchinclude and not matched by fetchexclude will have objects fetched for
+them.
Note that using the command-line options -I and -X override the respective
+configuration settings. Setting either option to an empty string clears the
+value.
git config lfs.fetchinclude "textures,images/foo*"
This will only fetch objects referenced in paths in the textures folder, and +files called foo* in the images folder
git config lfs.fetchinclude "*.jpg,*.png,*.tga"
Only fetch JPG/PNG/TGA files, wherever they are in the repository
git config lfs.fetchexclude "media/reallybigfiles"
Don't fetch any LFS objects referenced in the folder media/reallybigfiles, but +fetch everything else
git config lfs.fetchinclude "media"
+git config lfs.fetchexclude "media/excessive"
Only fetch LFS objects in the 'media' folder, but exclude those in one of its +subfolders.
Without arguments, fetch downloads from the default remote. The default remote
+is the same as for git fetch, i.e. based on the remote branch you're tracking
+first, or origin otherwise.
If no refs are given as arguments, the currently checked out ref is used. In +addition, if enabled, recently changed refs and commits are also +included. See RECENT CHANGES for details.
+ +If the --recent option is specified, or if the gitconfig option
+lfs.fetchrecentalways is true, then after the current ref (or those in the
+arguments) is fetched, we also search for 'recent' changes to fetch
+objects for, so that it's more convenient to checkout or diff those commits
+without incurring further downloads.
What changes are considered 'recent' is based on a number of gitconfig options:
+ +lfs.fetchrecentrefsdays
+If non-zero, includes branches which have commits within N days of the current
+date. Only local refs are included unless lfs.fetchrecentremoterefs is true.
+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 branches, also fetches changes made within N
+days of the latest commit on the branch. This is useful if you're often
+reviewing recent changes. The default is 0 (no previous changes).
lfs.fetchrecentalways
+Always operate as if --recent was provided on the command line.
Fetch the LFS objects for the current ref from default remote
+ +git lfs fetch
Fetch the LFS objects for the current ref AND recent changes from default +remote
+ +git lfs fetch --recent
Fetch the LFS objects for the current ref from a secondary remote 'upstream'
+ +git lfs fetch upstream
Fetch all the LFS objects from the default remote that are referenced by any
+commit in the main and develop branches
git lfs fetch --all origin main develop
Fetch the LFS objects for a branch from origin
+ +git lfs fetch origin mybranch
Fetch the LFS objects for 2 branches and a commit from origin
+ +git lfs fetch origin main mybranch e445b45c1c9c6282614f201b62778e4c0688b5c8
git-lfs-checkout(1), git-lfs-pull(1), git-lfs-prune(1).
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-filter-process - Git filter process that converts between pointer and actual content
+
git lfs filter-process
+git lfs filter-process --skip
Implement the Git process filter API, exchanging handshake messages and then +accepting and responding to requests to either clean or smudge a file.
+ +filter-process is always run by Git's filter process, and is configured by the +repository's Git attributes.
+ +The filter process uses Git's pkt-line protocol to communicate, and is +documented in detail in gitattributes(5).
+ +Without any options, filter-process accepts and responds to requests normally.
+ +--skipSkip automatic downloading of objects on clone or pull.
GIT_LFS_SKIP_SMUDGEDisables the smudging process. For more, see: git-lfs-config(5).
git-lfs-clean(1), git-lfs-install(1), git-lfs-smudge(1), gitattributes(5).
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-fsck - Check GIT LFS files for consistency
+
git lfs fsck [options] [revisions]
Checks all GIT LFS files in the current HEAD for consistency.
+ +Corrupted files are moved to ".git/lfs/bad".
+ +The revisions may be specified as either a single committish, in which case only
+that commit is inspected; specified as a range of the form A..B (and only this
+form), in which case that range is inspected; or omitted entirely, in which case
+HEAD (and, for --objects, the index) is examined.
The default is to perform all checks.
+ +--objects--pointersgit-lfs-ls-files(1), git-lfs-status(1).
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-install - Install Git LFS configuration.
+
git lfs install options
Perform the following actions to ensure that Git LFS is setup properly:
+ +Without any options, git lfs install will only setup the "lfs" smudge and clean
+filters if they are not already set.
--force--local--worktreeworktreeConfig must be enabled to use this option.
+ If only one working tree is in use, --worktree has the same effect
+ as --local.
+ This option is only available if the installed Git version is at least
+ 2.20.0 and therefore supports the "worktreeConfig" extension.--manualgit lfs install fails because of existing
+ hooks and you want to retain their functionality.--system--skip-smudge--skip-repogit-lfs-uninstall(1), git-worktree(1).
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-lock - Set a file as "locked" on the Git LFS server
+
git lfs lock options path
Sets the given file path as "locked" against the Git LFS server, with the +intention of blocking attempts by other users to update the given path. Locking +a file requires the file to exist in the working copy.
+ +Once locked, LFS will verify that Git pushes do not modify files locked by
+other users. See the description of the lfs.<url>.locksverify config key in
+git-lfs-config(5) for details.
-r name --remote=nameSpecify the Git LFS server to use. Ignored if the lfs.url config key is set.
--jsonWrites lock info as JSON to STDOUT if the command exits successfully. Intended +for interoperation with external tools. If the command returns with a non-zero +exit code, plain text messages will be sent to STDERR.
git-lfs-unlock(1), git-lfs-locks(1).
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-locks - Lists currently locked files from the Git LFS server.
+
git lfs locks options
Lists current locks from the Git LFS server.
+ +-r name --remote=nameSpecify the Git LFS server to use. Ignored if the lfs.url config key is set.
-i <id> --id=<id>Specifies a lock by its ID. Returns a single result.
-p <path> --path=<path>Specifies a lock by its path. Returns a single result.
--localLists only our own locks which are cached locally. Skips a remote call.
--cachedLists cached locks from the last remote call. Contrary to --local, this will +include locks of other users as well. This option is intended to display the +last known locks in case you are offline. There is no guarantee that locks +on the server have not changed in the meanwhile.
--verifyVerifies the lock owner on the server and marks our own locks by 'O'. +Own locks are actually held by us and corresponding files can be updated for +the next push. All other locks are held by someone else. +Contrary to --local, this option will also detect locks which are held by us +despite no local lock information being available (e.g. because the file had +been locked from a different clone); +it will also detect 'broken' locks (e.g. if someone else has forcefully +unlocked our files).
-l <num> --limit=<num>Specifies number of results to return.
--jsonWrites lock info as JSON to STDOUT if the command exits successfully. Intended +for interoperation with external tools. If the command returns with a non-zero +exit code, plain text messages will be sent to STDERR.
git-lfs-lock(1), git-lfs-unlock(1).
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-logs - Show errors from the git-lfs command
+
git lfs logs
+git lfs logs file
+git lfs logs clear
+git lfs logs boomtown
Display errors from the git-lfs command. Any time it crashes, the details are +saved to ".git/lfs/logs".
+ +clearClears all of the existing logged errors.
boomtownTriggers a dummy exception.
Without any options, git lfs logs simply shows the list of error logs.
Part of the git-lfs(1) suite.
+ + +
+ git-lfs-ls-files - Show information about Git LFS files in the index and working tree
+
git lfs ls-files [ref]
+git lfs ls-files ref ref
Display paths of Git LFS files that are found in the tree at the given +reference. If no reference is given, scan the currently checked-out branch. +If two references are given, the LFS files that are modified between the two +references are shown; deletions are not listed.
+ +An asterisk (*) after the OID indicates a full object, a minus (-) indicates an +LFS pointer.
+ +-l --longShow the entire 64 character OID, instead of just first 10.
-s --sizeShow the size of the LFS object between parenthesis at the end of a line.
-d --debugShow as much information as possible about a LFS file. This is intended +for manual inspection; the exact format may change at any time.
-a --allInspects the full history of the repository, not the current HEAD (or other +provided reference). This will include previous versions of LFS objects that +are no longer found in the current tree.
--deletedShows the full history of the given reference, including objects that have +been deleted.
-I paths --include=pathsInclude paths matching only these patterns; see [FETCH SETTINGS].
-X paths --exclude=pathsExclude paths matching any of these patterns; see [FETCH SETTINGS].
-n --name-onlyShow only the lfs tracked file names.
+ +git-lfs-status(1), git-lfs-config(5).
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-migrate - Migrate history to or from Git LFS
+
git lfs migrate mode [options] [--] [branch ...]
Convert files in a Git repository to or from Git LFS pointers, or
+summarize Git file sizes by file type. The import mode converts Git
+files (i.e., blobs) to Git LFS, while the export mode does the reverse,
+and the info mode provides an informational summary which may be useful
+in deciding which files to import or export.
In all modes, by default git lfs migrate operates only on the currently
+checked-out branch, and only on files (of any size and type) added in
+commits which do not exist on any remote. Multiple options are available
+to override these defaults.
When converting files to or from Git LFS, the git lfs migrate command will
+only make changes to your local repository and working copy, never any
+remotes. This is intentional as the import and export modes are
+generally "destructive" in the sense that they rewrite your Git history,
+changing commits and generating new commit SHAs. (The exception is the
+"no-rewrite" import sub-mode; see [IMPORT (NO REWRITE)] for details.)
You should therefore always first commit or stash any uncommitted work
+before using the import or export modes, and then validate the result of
+the migration before pushing the changes to your remotes, for instance by
+running the info mode and by examining your rewritten commit history.
Once you are satisfied with the changes, you will need to force-push the +new Git history of any rewritten branches to all your remotes. This is +a step which should be taken with care, since you will be altering the +Git history on your remotes.
+ +To examine or modify files in branches other than the currently checked-out
+one, branch refs may be specified directly, or provided in one or more
+--include-ref options. They may also be excluded by prefixing them
+with ^ or providing them in --exclude-ref options. Use the --everything
+option to specify that all refs should be examined, including all remote refs.
+See [INCLUDE AND EXCLUDE (REFS)] for details.
For the info and import modes, all file types are considered by default;
+while useful in the info mode, this is often not desirable when importing,
+so either filename patterns (pathspecs) or the --fixup option should
+normally be specified in that case. (At least one include pathspec is
+required for the export mode.) Pathspecs may be defined using the
+--include and --exclude options (-I and -X for short), as described
+in INCLUDE AND EXCLUDE.
As typical Git LFS usage depends on tracking specific file types using
+filename patterns defined in .gitattributes files, the git lfs migrate
+command will examine, create, and modify .gitattributes files as
+necessary.
The import mode (see IMPORT) will convert Git objects of the file types
+specified (e.g., with --include) to Git LFS pointers, and will add entries
+for those file types to .gitattributes files, creating those files if they
+do not exist. The result should be as if git lfs track commands had been
+run at the points in your Git history corresponding to where each type of
+converted file first appears. The exception is if the --fixup option is
+given, in which case the import mode will only examine any existing
+.gitattributes files and then convert Git objects which should be tracked
+by Git LFS but are not yet.
The export mode (see EXPORT) works as the reverse operation to the
+import mode, converting any Git LFS pointers that match the file types
+specified with --include, which must be given at least once. Note that
+.gitattributes entries will not be removed, nor will the files; instead,
+the export mode inserts "do not track" entries similar to those created
+by the git lfs untrack command. The --remote option is available in
+the export mode to specify the remote from which Git LFS objects should
+be fetched if they do not exist in the local Git LFS object cache; if not
+provided, origin is used by default.
The info mode (see INFO) summarizes by file type (i.e., by filename
+extension) the total number and size of files in a repository. Note that
+like the other two modes, by default the info mode operates only on
+the currently checked-out branch and only on commits which do not exist on
+any remote, so to get a summary of the entire repository across all branches,
+use the --everything option. If objects have already been converted to
+Git LFS pointers, then by default the size of the referenced objects is
+totaled and reported separately. You may also choose to ignore them by
+using --pointers=ignore or to treat the pointers as files by using
+--pointers=no-follow. (The latter option is akin to how existing Git LFS
+pointers were handled by the info mode in prior versions of Git LFS).
When using the --everything option, take note that it means all refs
+(local and remote) will be considered, but not necessarily all file types.
+The import and info modes consider all file types by default, although
+the --include and --exclude options constrain this behavior. Also
+note that after importing across all branches with the --everything option
+(and then checking to ensure the results are satisfactory!) it may be
+convenient to update multiple branches on your remotes by using the --all
+option to git push.
Unless the --skip-fetch option is given, git lfs migrate always begins by
+fetching updated lists of refs from all the remotes returned by git remote,
+but as noted above, after making changes to your local Git history while
+converting objects, it will never automatically push those changes to your
+remotes.
info
+ Show information about repository size. See INFO.
import
+ Convert Git objects to Git LFS pointers. See IMPORT and [IMPORT (NO REWRITE)].
export
+ Convert Git LFS pointers to Git objects. See EXPORT.
-I paths --include=pathsSee INCLUDE AND EXCLUDE.
-X paths --exclude=pathsSee INCLUDE AND EXCLUDE.
--include-ref=refnameSee [INCLUDE AND EXCLUDE (REFS)].
--exclude-ref=refnameSee [INCLUDE AND EXCLUDE (REFS)].
--skip-fetch Assumes that the known set of remote references is complete, and should not
+ be refreshed when determining the set of "un-pushed" commits to migrate. Has
+ no effect when combined with --include-ref or --exclude-ref.
--everythingSee [INCLUDE AND EXCLUDE (REFS)].
+ + Note: Git refs are "case-sensitive" on all platforms in "packed from" (see
+ git-pack-refs(1)). On "case-insensitive" file systems, e.g. NTFS on Windows
+ or default APFS on macOS, git-lfs-migrate(1) would only migrate the first
+ ref if two or more refs are equal except for upper/lower case letters.
--yesAssume a yes answer to any prompts, permitting noninteractive use. + Currently, the only such prompt is the one asking whether to overwrite + (destroy) any working copy changes. Thus, specifying this option may cause + data loss if you are not careful.
Migrate only the set of branches listed. If not given, git-lfs-migrate(1)
+ will migrate the currently checked out branch.
References beginning with ^ will be excluded, whereas branches that do not
+ begin with ^ will be included.
If any of --include-ref or --exclude-ref are given, the checked out
+ branch will not be appended, but branches given explicitly will be appended.
The info mode summarizes the sizes of file objects present in the Git history.
+It supports all the core migrate options and these additional ones:
--above=<size>
+ Only count files whose individual filesize is above the given size. size
+ may be specified as a number of bytes, or a number followed by a storage
+ unit, e.g., "1b", "20 MB", "3 TiB", etc.
If a set of files sharing a common extension has no files in that set whose
+ individual size is above the given --above no files no entry for that set
+ will be shown.
--top=<n>
+ Only display the top n entries, ordered by how many total files match the
+ given pathspec. The default is to show only the top 5 entries. When
+ existing Git LFS objects are found, an extra, separate "LFS Objects" line
+ is output in addition to the top n entries, unless the --pointers
+ option is used to change this behavior.
--unit=<unit>
+ Format the number of bytes in each entry as a quantity of the storage unit
+ provided. Valid units include:
* b, kib, mib, gib, tib, pib - for IEC storage units
+* b, kb, mb, gb, tb, pb - for SI storage units
+ If a --unit is not specified, the largest unit that can fit the number of
+ counted bytes as a whole number quantity is chosen.
--pointers=[follow|no-follow|ignore]
+ Treat existing Git LFS pointers in the history according to one of three
+ alternatives. In the default follow case, if any pointers are found,
+ an additional separate "LFS Objects" line item is output which summarizes
+ the total number and size of the Git LFS objects referenced by pointers.
+ In the ignore case, any pointers are simply ignored, while the no-follow
+ case replicates the behavior of the info mode in older Git LFS versions
+ and treats any pointers it finds as if they were regular files, so the
+ output totals only include the contents of the pointers, not the contents
+ of the objects to which they refer.
--fixup
+ Infer --include and --exclude filters on a per-commit basis based on the
+ .gitattributes files in a repository. In practice, this option counts any
+ filepaths which should be tracked by Git LFS according to the repository's
+ .gitattributes file(s), but aren't already pointers. The .gitattributes
+ files are not reported, in contrast to the normal output of the info mode.
+ This option is incompatible with explicitly given --include, --exclude
+ filters and with any --pointers setting other than ignore, hence
+ --fixup implies --pointers=ignore if it is not explicitly set.
The format of the output shows the filename pattern, the total size of the
+file objects (excluding those below the --above threshold, if one was
+defined), and the ratio of the number of files above the threshold to the
+total number of files; this ratio is also shown as a percentage. For example:
*.gif 93 MB 9480/10504 files(s) 90%
+*.png 14 MB 1732/1877 files(s) 92%
+By default only the top five entries are shown, but --top allows for
+more or fewer to be output as desired.
The import mode migrates objects present in the Git history to pointer
+files tracked and stored with Git LFS. It supports all the core migrate
+options and these additional ones:
--verbose
+ Print the commit oid and filename of migrated files to STDOUT.
--above=<size>
+ Only migrate files whose individual filesize is above the given size. size
+ may be specified as a number of bytes, or a number followed by a storage
+ unit, e.g., "1b", "20 MB", "3 TiB", etc.
--object-map=<path>
+ Write to path a file with the mapping of each rewritten commits. The file
+ format is CSV with this pattern: OLD-SHA,NEW-SHA
--no-rewrite
+ Migrate objects to Git LFS in a new commit without rewriting Git
+ history. Please note that when this option is used, the migrate import
+ command will expect a different argument list, specialized options will
+ become available, and the core migrate options will be ignored. See
+ [IMPORT (NO REWRITE)].
--fixup
+ Infer --include and --exclude filters on a per-commit basis based on the
+ .gitattributes files in a repository. In practice, this option imports any
+ filepaths which should be tracked by Git LFS according to the repository's
+ .gitattributes file(s), but aren't already pointers. This option is
+ incompatible with explicitly given --include, --exclude filters.
If --no-rewrite is not provided and --include or --exclude (-I, -X,
+respectively) are given, the .gitattributes will be modified to include any
+new filepath patterns as given by those flags.
If --no-rewrite is not provided and neither of those flags are given, the
+gitattributes will be incrementally modified to include new filepath extensions
+as they are rewritten in history.
The import mode has a special sub-mode enabled by the --no-rewrite flag.
+This sub-mode will migrate objects to pointers as in the base import
+mode, but will do so in a new commit without rewriting Git history. When using
+this sub-mode, the base migrate options, such as --include-ref, will be
+ignored, as will those for the base import mode. The migrate command will
+also take a different argument list. As a result of these changes,
+--no-rewrite will only operate on the current branch - any other interested
+branches must have the generated commit merged in.
The --no-rewrite sub-mode supports the following options and arguments:
-m <message> --message=<message>
+ Specifies a commit message for the newly created commit.
[file ...] + The list of files to import. These files must be tracked by patterns + specified in the gitattributes.
If --message is given, the new commit will be created with the provided
+message. If no message is given, a commit message will be generated based on the
+file arguments.
The export mode migrates Git LFS pointer files present in the Git history out
+of Git LFS, converting them into their corresponding object files. It supports
+all the core migrate options and these additional ones:
--verbose
+ Print the commit oid and filename of migrated files to STDOUT.
--object-map=<path>
+ Write to path a file with the mapping of each rewritten commit. The file
+ format is CSV with this pattern: OLD-SHA,NEW-SHA
--remote=<git-remote>
+ Download LFS objects from the provided git-remote during the export. If
+ not provided, defaults to origin.
The export mode requires at minimum a pattern provided with the --include
+argument to specify which files to export. Files matching the --include
+patterns will be removed from Git LFS, while files matching the --exclude
+patterns will retain their Git LFS status. The export command will modify the
+.gitattributes to set/unset any filepath patterns as given by those flags.
You can specify that git lfs migrate should only convert files whose
+pathspec matches the --include glob patterns and does not match the
+--exclude glob patterns, either to reduce total migration time or to only
+migrate part of your repo. Multiple patterns may be given using commas
+as delimiters.
Pattern matching is done so as to be functionally equivalent to the pattern
+matching format of .gitattributes. In addition to simple file extension
+matches (e.g., *.gif) patterns may also specify directory paths, in which
+case the path/** format may be used to match recursively.
You can specify that git lfs migrate should only convert files added
+in commits reachable from certain references, namely those defined using one
+or more --include-ref options, and should ignore files in commits reachable
+from references defined in --exclude-ref options.
D---E---F
+ / \
+ A---B------C refs/heads/my-feature
+ \ \
+ \ refs/heads/main
+ \
+ refs/remotes/origin/main
+In the above configuration, the following commits are reachable by each ref:
+ +refs/heads/main: C, B, A
+refs/heads/my-feature: F, E, D, B, A
+refs/remote/origin/main: A
+The following git lfs migrate options would, therefore, include commits
+F, E, D, C, and B, but exclude commit A:
--include-ref=refs/heads/my-feature
+ --include-ref=refs/heads/main
+ --exclude-ref=refs/remotes/origin/main
+The presence of flag --everything indicates that all local and remote
+references should be migrated.
A common use case for the migrate command is to convert large Git objects to +LFS before pushing your commits. By default, it only scans commits that don't +exist on any remote, so long as the repository is non-bare.
+ +First, run git lfs migrate info to list the file types taking up the most
+space in your repository:
$ git lfs migrate info
+migrate: Fetching remote refs: ..., done
+migrate: Sorting commits: ..., done
+migrate: Examining commits: 100% (1/1), done
+*.mp3 284 MB 1/1 files(s) 100%
+*.pdf 42 MB 8/8 files(s) 100%
+*.psd 9.8 MB 15/15 files(s) 100%
+*.ipynb 6.9 MB 6/6 files(s) 100%
+*.csv 5.8 MB 2/2 files(s) 100%
+Now, you can run git lfs migrate import to convert some file types to LFS:
$ git lfs migrate import --include="*.mp3,*.psd"
+migrate: Fetching remote refs: ..., done
+migrate: Sorting commits: ..., done
+migrate: Rewriting commits: 100% (1/1), done
+ main d2b959babd099fe70da1c1512e2475e8a24de163 -> 136e706bf1ae79643915c134e17a6c933fd53c61
+migrate: Updating refs: ..., done
+If after conversion you find that some files in your working directory have
+been replaced with Git LFS pointers, this is normal, and the working copies
+of these files can be repopulated with their full expected contents by using
+git lfs checkout.
You can also migrate the entire history of your repository:
+ +# Check for large files and existing Git LFS objects in your local main branch
+$ git lfs migrate info --include-ref=main
+
+# Check for large files and existing Git LFS objects in every branch
+$ git lfs migrate info --everything
+
+# Check for large files in every branch, ignoring any existing Git LFS objects,
+# and listing the top 100 or fewer results
+$ git lfs migrate info --everything --pointers=ignore --top=100
+The same flags will work in import mode:
# Convert all zip files in your main branch
+$ git lfs migrate import --include-ref=main --include="*.zip"
+
+# Convert all zip files in every local branch
+$ git lfs migrate import --everything --include="*.zip"
+
+# Convert all files over 100K in every local branch
+$ git lfs migrate import --everything --above=100Kb
+Note: This will require a force-push to any existing Git remotes. Using
+the --all option when force-pushing may be convenient if many refs were
+updated, e.g., after importing to Git LFS with the --everything option.
You can also migrate files without modifying the existing history of your +repository. Note that in the examples below, files in subdirectories are not +included because they are not explicitly specified.
+ +Without a specified commit message:
+ +$ git lfs migrate import --no-rewrite test.zip *.mp3 *.psd
+With a specified commit message:
+ +$ git lfs migrate import --no-rewrite \
+ -m "Import test.zip, .mp3, .psd files in root of repo" \
+ test.zip *.mp3 *.psd
+git-lfs-checkout(1), git-lfs-track(1), git-lfs-untrack(1), gitattributes(5).
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-pointer - Build, compare, and check pointers
+
git lfs pointer --file=path/to/file
+git lfs pointer --file=path/to/file --pointer=path/to/pointer
+git lfs pointer --file=path/to/file --stdin
+git lfs pointer --check --file=path/to/file
Builds and optionally compares generated pointer files to ensure consistency +between different Git LFS implementations.
+ +--fileA local file to build the pointer from.
--pointer A local file including the contents of a pointer generated from another
+ implementation. This is compared to the pointer generated from --file.
--stdin Reads the pointer from STDIN to compare with the pointer generated from
+ --file.
--check Reads the pointer from STDIN (if --stdin is given) or the filepath (if
+ --file) is given. If neither or both of --stdin and --file are given,
+ the invocation is invalid. Exits 0 if the data read is a valid Git LFS
+ pointer. Exits 1 otherwise.
--strict:--no-strict--check, --strict verifies that the pointer is
+ canonical; that is, it would be the one created by Git LFS. If it is not,
+ exits 2. The default, for backwards compatibility, is --no-strict, but
+ this may change in a future version.Part of the git-lfs(1) suite.
+ + +
+ git-lfs-post-checkout - Git post-checkout hook implementation
+
git lfs post-checkout rev_before ref_after is_branch_checkout
Responds to Git post-checkout events. It makes sure that any files which are
+marked as lockable by git lfs track are read-only in the working copy, if
+not currently locked by the local user.
git-lfs-track(1)
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-post-commit - Git post-commit hook implementation
+
git lfs post-commit
Responds to Git post-commit events. It makes sure that any files which are
+marked as lockable by git lfs track are read-only in the working copy, if
+not currently locked by the local user.
Where the git lfs post-merge command, which has a similar purpose, must
+examine all files in the working copy, git lfs post-commit can limit
+itself checking only those files which have changed in HEAD. It primarily
+handles newly added lockable files which have not yet been made read-only.
git-lfs-post-merge(1), git-lfs-track(1)
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-post-merge - Git post-merge hook implementation
+
git lfs post-merge is_squash
Responds to Git post-merge events. It makes sure that any files which are
+marked as lockable by git lfs track are read-only in the working copy, if
+not currently locked by the local user.
git-lfs-track(1)
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-pre-push - Git pre-push hook implementation
+
git lfs pre-push remote [remoteurl]
Responds to Git pre-hook events. It reads the range of commits from STDIN, in +the following format:
+ +<local-ref> SP <local-sha1> SP <remote-ref> SP <remote-sha1> \n
+It also takes the remote name and URL as arguments.
+ +If any of those Git objects are associated with Git LFS objects, those +objects will be pushed to the Git LFS API.
+ +In the case of pushing a new branch, the list of Git objects will be all of +the Git objects in this branch.
+ +In the case of deleting a branch, no attempts to push Git LFS objects will be +made.
+ +GIT_LFS_SKIP_PUSHgit-lfs-clean(1), git-lfs-push(1).
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-prune - Delete old LFS files from local storage
+
git lfs prune options
Deletes local copies of LFS files which are old, thus freeing up disk space. +Prune operates by enumerating all the locally stored objects, and then deleting +any which are not referenced by at least ONE of the following:
+ +In general terms, prune will delete files you're not currently using and which +are not 'recent', so long as they've been pushed i.e. the local copy is not the +only one.
+ +The reflog is not considered, only commits. Therefore LFS objects that are +only referenced by orphaned commits are always deleted.
+ +Note: you should not run git lfs prune if you have different repositories
+sharing the same custom storage directory; see git-lfs-config(1) for more
+details about lfs.storage option.
--dry-run -d
+Don't actually delete anything, just report on what would have been done
--force -f
+Prune all objects except unpushed objects, including objects required for
+currently checked out refs. Implies --recent.
--recent
+Prune even objects that would normally be preserved by the configuration
+options specified below in RECENT FILES.
--verify-remote -c
+Contact the remote and check that copies of the files we would delete
+definitely exist before deleting. See VERIFY REMOTE.
--no-verify-remote
+Disables remote verification if lfs.pruneverifyremotealways was enabled in
+settings. See VERIFY REMOTE.
--verbose -v
+Report the full detail of what is/would be deleted.
Prune won't delete LFS files referenced by 'recent' commits, in case you want
+to use them again without having to download. The definition of 'recent' is
+derived from the one used by git-lfs-fetch(1) to download recent objects with
+the --recent option, with an offset of a number of days (default 3) to ensure
+that we always keep files you download for a few days.
Here are the git-config(1) settings that control this behaviour:
+ +lfs.pruneoffsetdays
+The number of extra days added to the fetch recent settings when using them
+to decide when to prune. So for a reference to be considered old enough to
+prune, it has to be this many days older than the oldest reference that would
+be downloaded via git lfs fetch --recent. Only used if the relevant
+fetch recent 'days' setting is non-zero. Default 3 days.
lfs.fetchrecentrefsdays
+lfs.fetchrecentremoterefs
+lfs.fetchrecentcommitsdays
+These have the same meaning as git-lfs-fetch(1) with the --recent option,
+they are used as a base for the offset above. Anything which falls outside
+of this offsetted window is considered old enough to prune. If a day value is
+zero, that condition is not used at all to retain objects and they will be
+pruned.
When the only copy of an LFS file is local, and it is still reachable from any +reference, that file can never be pruned, regardless of how old it is.
+ +To determine whether an LFS file has been pushed, we check the difference +between local refs and remote refs; where the local ref is ahead, any LFS files +referenced in those commits is unpushed and will not be deleted. This works +because the LFS pre-push hook always ensures that LFS files are pushed before +the remote branch is updated.
+ +See DEFAULT REMOTE, for which remote is considered 'pushed' for pruning +purposes.
+ +The --verify-remote option calls the remote to ensure that any LFS files to be
+deleted have copies on the remote before actually deleting them.
Usually the check performed by UNPUSHED LFS FILES is enough to determine that +files have been pushed, but if you want to be extra sure at the expense of extra +overhead you can make prune actually call the remote API and verify the +presence of the files you're about to delete locally. See DEFAULT REMOTE for +which remote is checked.
+ +You can make this behaviour the default by setting lfs.pruneverifyremotealways
+to true.
In addition to the overhead of calling the remote, using this option also +requires prune to distinguish between totally unreachable files (e.g. those that +were added to the index but never committed, or referenced only by orphaned +commits), and files which are still referenced, but by commits which are +prunable. This makes the prune process take longer.
+ +When identifying UNPUSHED LFS FILES and performing VERIFY REMOTE, a single +remote, 'origin', is normally used as the reference. This one remote is +considered canonical; even if you use multiple remotes, you probably want to +retain your local copies until they've made it to that remote. 'origin' is used +by default because that will usually be a main central repo, or your fork of +it - in both cases that's a valid remote backup of your work. If origin doesn't +exist then by default nothing will be pruned because everything is treated as +'unpushed'.
+ +You can alter the remote via git config: lfs.pruneremotetocheck. Set this
+to a different remote name to check that one instead of 'origin'.
git-lfs-fetch(1)
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-pull - Download all Git LFS files for current ref & checkout
+
git lfs pull [options] [remote]
Download Git LFS objects for the currently checked out ref, and update +the working copy with the downloaded content if required.
+ +This is equivalent to running the following 2 commands:
+ +git lfs fetch [options] [remote] +git lfs checkout
+ +-I paths --include=pathsSpecify lfs.fetchinclude just for this invocation; see [INCLUSION & EXCLUSION]
-X paths --exclude=pathsSpecify lfs.fetchexclude just for this invocation; see [INCLUSION & EXCLUSION]
You can configure Git LFS to only fetch objects to satisfy references in certain +paths of the repo, and/or to exclude certain paths of the repo, to reduce the +time you spend downloading things you do not use.
+ +In gitconfig, set lfs.fetchinclude and lfs.fetchexclude to comma-separated lists +of paths to include/exclude in the fetch (wildcard matching as per gitignore). +Only paths which are matched by fetchinclude and not matched by fetchexclude +will have objects fetched for them.
+ +Note that using the command-line options -I and -X override the respective
+configuration settings. Setting either option to an empty string clears the
+value.
Without arguments, pull downloads from the default remote. The default remote is
+the same as for git pull, i.e. based on the remote branch you're tracking
+first, or origin otherwise.
git-lfs-fetch(1), git-lfs-checkout(1).
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-push - Push queued large files to the Git LFS endpoint
+
git lfs push options remote [ref...]
+git lfs push remote [ref...]
+git lfs push --object-id remote [oid...]
Upload Git LFS files to the configured endpoint for the current Git remote. By +default, it filters out objects that are already referenced by the local clone +of the remote.
+ +--dry-runPrint the files that would be pushed, without actually pushing them.
--allThis pushes all objects to the remote that are referenced by any commit + reachable from the refs provided as arguments. If no refs are provided, then + all refs are pushed.
--object-idThis pushes only the object OIDs listed at the end of the command, separated + by spaces.
git-lfs-pre-push(1).
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-smudge - Git smudge filter that converts pointer in blobs to the actual content
+
git lfs smudge [path]
+git lfs smudge --skip [path]
Read a Git LFS pointer file from standard input and write the contents +of the corresponding large file to standard output. If needed, +download the file's contents from the Git LFS endpoint. The path +argument, if provided, is only used for a progress bar.
+ +Smudge is typically run by Git's smudge filter, configured by the repository's +Git attributes.
+ +Without any options, git lfs smudge outputs the raw Git LFS content to
+standard output.
--skipSkip automatic downloading of objects on clone or pull.
GIT_LFS_SKIP_SMUDGEDisables the smudging process. For more, see: git-lfs-config(5).
On Windows, Git does not handle files in the working tree larger than 4 +gigabytes.
+ +For more information, see: https://github.com/git-lfs/git-lfs/issues/2434.
+ +git-lfs-install(1), gitattributes(5).
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-status - Show the status of Git LFS files in the working tree
+
git lfs status [options]
Display paths of Git LFS objects that
+ +have not been pushed to the Git LFS server. These are large files
+that would be uploaded by git push.
have differences between the index file and the current HEAD commit.
+These are large files that would be committed by git commit.
have differences between the working tree and the index file. These
+are files that could be staged using git add.
This command must be run in a non-bare repository.
+ +--porcelain--jsongit-lfs-ls-files(1).
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-track - View or add Git LFS paths to Git attributes
+
git lfs track [options] [pattern...]
Start tracking the given patterns(s) through Git LFS. The pattern argument +is written to .gitattributes. If no paths are provided, simply list the +currently-tracked paths.
+ +The gitattributes documentation states
+that patterns use the gitignore pattern rules
+to match paths. This means that patterns which contain asterisk (*), question
+mark (?), and the bracket characters ([ and ]) are treated specially; to
+disable this behavior and treat them literally instead, use --filename or
+escape the character with a backslash.
--verbose -v:
+If enabled, have git lfs track log files which it will touch. Disabled by
+default.
--dry-run -d:
+If enabled, have git lfs track log all actions it would normally take
+(adding entries to .gitattributes, touching files on disk, etc) without
+performing any mutative operations to the disk.
git lfs track --dry-run [files] also implicitly mocks the behavior of
+passing the --verbose, and will log in greater detail what it is doing.
Disabled by default.
--filename
+Treat the arguments as literal filenames, not as patterns. Any special glob
+characters in the filename will be escaped when writing the .gitattributes
+file.
--lockable -l
+Make the paths 'lockable', meaning they should be locked to edit them, and
+will be made read-only in the working copy when not locked.
--not-lockable
+Remove the lockable flag from the paths so they are no longer read-only unless
+locked.
--no-excluded
+Do not list patterns that are excluded in the output; only list patterns that
+are tracked.
--no-modify-attrs
+Makes matched entries stat-dirty so that Git can re-index files you wish to
+convert to LFS. Does not modify any .gitattributes file(s).
git lfs track
git lfs track "*.gif"
git lfs track --lockable "*.psd"
project [1].psd: git lfs track --filename "project [1].psd"
git-lfs-untrack(1), git-lfs-install(1), gitattributes(5), gitignore(5).
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-uninstall - Remove Git LFS configuration
+
git lfs uninstall
Perform the following actions to remove the Git LFS configuration:
+ +worktreeConfig must be enabled to use this option.
+ If only one working tree is in use, --worktree has the same effect
+ as --local.
+ This option is only available if the installed Git version is at least
+ 2.20.0 and therefore supports the "worktreeConfig" extension.git-lfs-install(1), git-worktree(1).
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-unlock - Remove "locked" setting for a file on the Git LFS server
+
git lfs unlock OPTIONS path
Removes the given file path as "locked" on the Git LFS server. Files must exist
+and have a clean git status before they can be unlocked. The --force flag will
+skip these checks.
-r name --remote=nameSpecify the Git LFS server to use. Ignored if the lfs.url config key is set.
-f --forceTells the server to remove the lock, even if it's owned by another user.
-i <id> --id=<id>Specifies a lock by its ID instead of path.
--jsonWrites lock info as JSON to STDOUT if the command exits successfully. Intended +for interoperation with external tools. If the command returns with a non-zero +exit code, plain text messages will be sent to STDERR.
git-lfs-lock(1), git-lfs-locks(1).
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-untrack - Remove Git LFS paths from Git Attributes
+
git lfs untrack path...
Stop tracking the given path(s) through Git LFS. The path argument +can be a glob pattern or a file path.
+ + git lfs untrack "*.gif"
git-lfs-track(1), git-lfs-install(1), gitattributes(5).
+ +Part of the git-lfs(1) suite.
+ + +
+ git-lfs-update - Update Git hooks
+
git lfs update [--manual | --force]
Updates the Git hooks used by Git LFS. Silently upgrades known hook contents. +If you have your own custom hooks you may need to use one of the extended +options below.
+ +--manual -m
+ Print instructions for manually updating your hooks to include git-lfs
+ functionality. Use this option if git lfs update fails because of existing
+ hooks and you want to retain their functionality.
--force -f
+ Forcibly overwrite any existing hooks with git-lfs hooks. Use this option
+ if git lfs update fails because of existing hooks but you don't care
+ about their current contents.
Part of the git-lfs(1) suite.
+ + +
+ git-lfs - Work with large files in Git repositories
+
git lfs command [args]
Git LFS is a system for managing and versioning large files in +association with a Git repository. Instead of storing the large files +within the Git repository as blobs, Git LFS stores special "pointer +files" in the repository, while storing the actual file contents on a +Git LFS server. The contents of the large file are downloaded +automatically when needed, for example when a Git branch containing +the large file is checked out.
+ +Git LFS works by using a "smudge" filter to look up the large file
+contents based on the pointer file, and a "clean" filter to create a
+new version of the pointer file when the large file's contents change.
+It also uses a pre-push hook to upload the large file contents to
+the Git LFS server whenever a commit containing a new large file
+version is about to be pushed to the corresponding Git server.
Like Git, Git LFS commands are separated into high level ("porcelain") +commands and low level ("plumbing") commands.
+ +To get started with Git LFS, the following commands can be used.
+ +Setup Git LFS on your system. You only have to do this once per +repository per machine:
+ +git lfs install
+Choose the type of files you want to track, for examples all ISO
+images, with git-lfs-track(1):
git lfs track "*.iso"
+The above stores this information in gitattributes(5) files, so +that file need to be added to the repository:
+ +git add .gitattributes
+Commit, push and work with the files normally:
+ +git add file.iso
+git commit -m "Add disk image"
+git push
+