+```
+
+The [official documentation](docs) has command references and specifications for
+the tool. There's also a [FAQ](https://github.com/git-lfs/git-lfs/wiki/FAQ) on
+the wiki which answers some common questions.
+
+If you have a question on how to use Git LFS, aren't sure about something, or
+are looking for input from others on tips about best practices or use cases,
+feel free to
+[start a discussion](https://github.com/git-lfs/git-lfs/discussions).
+
+You can always [open an issue](https://github.com/git-lfs/git-lfs/issues), and
+one of the Core Team members will respond to you. Please be sure to include:
+
+1. The output of `git lfs env`, which displays helpful information about your
+ Git repository useful in debugging.
+2. Any failed commands re-run with `GIT_TRACE=1` in the environment, which
+ displays additional information pertaining to why a command crashed.
+
+## Contributing
+
+See [CONTRIBUTING.md](CONTRIBUTING.md) for info on working on Git LFS and
+sending patches. Related projects are listed on the [Implementations wiki
+page](https://github.com/git-lfs/git-lfs/wiki/Implementations).
+
+See also [SECURITY.md](SECURITY.md) for info on how to submit reports
+of security vulnerabilities.
+
+## Core Team
+
+These are the humans that form the Git LFS core team, which runs the project.
+
+In alphabetical order:
+
+| [@bk2204][bk2204-user] | [@chrisd8088][chrisd8088-user] | [@larsxschneider][larsxschneider-user] |
+| :---: | :---: | :---: |
+| [![][bk2204-img]][bk2204-user] | [![][chrisd8088-img]][chrisd8088-user] | [![][larsxschneider-img]][larsxschneider-user] |
+| [PGP 0223B187][bk2204-pgp] | [PGP 088335A9][chrisd8088-pgp] | [PGP A5795889][larsxschneider-pgp] |
+
+[bk2204-img]: https://avatars1.githubusercontent.com/u/497054?s=100&v=4
+[chrisd8088-img]: https://avatars1.githubusercontent.com/u/28857117?s=100&v=4
+[larsxschneider-img]: https://avatars1.githubusercontent.com/u/477434?s=100&v=4
+[bk2204-user]: https://github.com/bk2204
+[chrisd8088-user]: https://github.com/chrisd8088
+[larsxschneider-user]: https://github.com/larsxschneider
+[bk2204-pgp]: https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x88ace9b29196305ba9947552f1ba225c0223b187
+[chrisd8088-pgp]: https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x86cd3297749375bcf8206715f54fe648088335a9
+[larsxschneider-pgp]: https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xaa3b3450295830d2de6db90caba67be5a5795889
+
+### Alumni
+
+These are the humans that have in the past formed the Git LFS core team, or
+have otherwise contributed a significant amount to the project. Git LFS would
+not be possible without them.
+
+In alphabetical order:
+
+| [@andyneff][andyneff-user] | [@PastelMobileSuit][PastelMobileSuit-user] | [@rubyist][rubyist-user] | [@sinbad][sinbad-user] | [@technoweenie][technoweenie-user] | [@ttaylorr][ttaylorr-user] |
+| :---: | :---: | :---: | :---: | :---: | :---: |
+| [![][andyneff-img]][andyneff-user] | [![][PastelMobileSuit-img]][PastelMobileSuit-user] | [![][rubyist-img]][rubyist-user] | [![][sinbad-img]][sinbad-user] | [![][technoweenie-img]][technoweenie-user] | [![][ttaylorr-img]][ttaylorr-user] |
+
+[andyneff-img]: https://avatars1.githubusercontent.com/u/7596961?v=3&s=100
+[PastelMobileSuit-img]: https://avatars2.githubusercontent.com/u/37254014?s=100&v=4
+[rubyist-img]: https://avatars1.githubusercontent.com/u/143?v=3&s=100
+[sinbad-img]: https://avatars1.githubusercontent.com/u/142735?v=3&s=100
+[technoweenie-img]: https://avatars3.githubusercontent.com/u/21?v=3&s=100
+[ttaylorr-img]: https://avatars2.githubusercontent.com/u/443245?s=100&v=4
+[andyneff-user]: https://github.com/andyneff
+[PastelMobileSuit-user]: https://github.com/PastelMobileSuit
+[sinbad-user]: https://github.com/sinbad
+[rubyist-user]: https://github.com/rubyist
+[technoweenie-user]: https://github.com/technoweenie
+[ttaylorr-user]: https://github.com/ttaylorr
diff --git a/git-lfs-3.2.0/git-lfs b/git-lfs-3.2.0/git-lfs
new file mode 100644
index 0000000000000000000000000000000000000000..96092eb2c4ad5c0737aa541dff7d352baa28fe0c
--- /dev/null
+++ b/git-lfs-3.2.0/git-lfs
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:05309d4bc952e77251de76d8dda6bfbb9e9f532757abfc41a454f0e8327d7e33
+size 10768384
diff --git a/git-lfs-3.2.0/install.sh b/git-lfs-3.2.0/install.sh
new file mode 100644
index 0000000000000000000000000000000000000000..28e45f1b6f474e039cf05700e3fd43c85876dc15
--- /dev/null
+++ b/git-lfs-3.2.0/install.sh
@@ -0,0 +1,22 @@
+#!/usr/bin/env bash
+set -eu
+
+prefix="/usr/local"
+
+if [ "${PREFIX:-}" != "" ] ; then
+ prefix=${PREFIX:-}
+elif [ "${BOXEN_HOME:-}" != "" ] ; then
+ prefix=${BOXEN_HOME:-}
+fi
+
+mkdir -p $prefix/bin
+rm -rf $prefix/bin/git-lfs*
+
+pushd "$( dirname "${BASH_SOURCE[0]}" )" > /dev/null
+ for g in git*; do
+ install $g "$prefix/bin/$g"
+ done
+popd > /dev/null
+
+PATH+=:$prefix/bin
+git lfs install
diff --git a/git-lfs-3.2.0/man/html/git-lfs-checkout.1.html b/git-lfs-3.2.0/man/html/git-lfs-checkout.1.html
new file mode 100644
index 0000000000000000000000000000000000000000..9455cb3c1789d55ecfd8f6b132266540e4f3e2b3
--- /dev/null
+++ b/git-lfs-3.2.0/man/html/git-lfs-checkout.1.html
@@ -0,0 +1,178 @@
+
+
+
+
+
+ git-lfs-checkout(1) - Update working copy with file content if available
+
+
+
+
+
+
+
+
+
+ - git-lfs-checkout(1)
+
+ - git-lfs-checkout(1)
+
+
+
+
+
NAME
+
+ git-lfs-checkout - Update working copy with file content if available
+
+
SYNOPSIS
+
+
git lfs checkout [glob-pattern...]
+git lfs checkout --to file {--base|--ours|--theirs} conflict-obj-path
+
+
DESCRIPTION
+
+
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.
+
+
One or more glob-patterns may be provided as arguments to restrict the
+set of files that are updated. Glob patterns are matched as per the format
+described in gitignore(5).
+
+
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 a conflicting Git LFS
+object into a separate file (which can be outside of the work tree).
+This can make using diff tools to inspect and resolve merges easier.
+A single Git LFS object's file path must be provided in conflict-obj-path.
+
+
OPTIONS
+
+
+--base- Check out the merge base of the specified file.
+--ours- Check out our side (that of the current branch) of the conflict for the
+specified file.
+--theirs- Check out their side (that of the other branch) of the conflict for the
+specified file.
+-
+
--to path
+
+- If 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.
+
+
+
EXAMPLES
+
+
+- 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
+
+
+
+- Checkout a path with a merge conflict into separate files:
+
+
+
+
```
+# Attempt merge with a branch that has a merge conflict
+$ git merge conflicting-branch
+CONFLICT (content): Merge conflict in path/to/conflicting/file.dat
+
+
Checkout versions of the conflicting file into temp files
+
$ git lfs checkout ours.dat --ours path/to/conflicting/file.dat
+$ git lfs checkout theirs.dat --theirs path/to/conflicting/file.dat
+
+
Compare conflicting versions in ours.dat and theirs.dat,
+
# then resolve conflict (e.g., by choosing one version over
+# the other, or creating a new version)
+
+
Cleanup and continue with merge
+
$ rm ours.dat theirs.dat
+$ git add path/to/conflicting/file.dat
+$ git merge --continue
+```
+
+
SEE ALSO
+
+
git-lfs-fetch(1), git-lfs-pull(1), gitignore(5).
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-clean(1)
+
+ - git-lfs-clean(1)
+
+
+
+
+
NAME
+
+ git-lfs-clean - Git clean filter that converts large files to pointers
+
+
SYNOPSIS
+
+
git lfs clean path
+
+
DESCRIPTION
+
+
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.
+
+
SEE ALSO
+
+
git-lfs-install(1), git-lfs-push(1), git-lfs-pointer(1), gitattributes(5).
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-clone(1)
+
+ - git-lfs-clone(1)
+
+
+
+
+
NAME
+
+ git-lfs-clone - Efficiently clone a LFS-enabled repository
+
+
SYNOPSIS
+
+
git lfs clone [git clone options] repository [directory]
+
+
DESCRIPTION
+
+
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'.
+
+
OPTIONS
+
+
All options supported by 'git clone'
+
+
+-
+
-I paths --include=paths
+
+- See INCLUDE AND EXCLUDE
+
+-
+
-X paths --exclude=paths
+
+- See INCLUDE AND EXCLUDE
+
+--skip-repo- Skip installing repo-level hooks (.git/hooks) that LFS requires. Disabled by
+default.
+
+
+
INCLUDE AND EXCLUDE
+
+
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 your Git configuration or in a .lfsconfig file, you may set either or
+both of lfs.fetchinclude and lfs.fetchexclude to comma-separated lists of
+paths. If lfs.fetchinclude is defined, Git LFS objects will only be fetched
+if their path matches one in that list, and if lfs.fetchexclude is defined,
+Git LFS objects will only be fetched if their path does not match one
+in that list. Paths are matched using wildcard matching as per gitignore(5).
+
+
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.
+
+
SEE ALSO
+
+
git-clone(1), git-lfs-pull(1), gitignore(5).
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-config(5)
+
+ - git-lfs-config(5)
+
+
+
+
+
NAME
+
+ git-lfs-config - Configuration options for git-lfs
+
+
CONFIGURATION FILES
+
+
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.
+
+
LIST OF OPTIONS
+
+
General settings
+
+
+ -
+
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) with a Git for Windows version less than
+2.34.0 due to a limitation in Git. Default: true if the version is less than
+2.34.0, false otherwise.
+
+
+
+
Upload and download transfer settings
+
+
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.
+
+
+
+
Push settings
+
+
+
+
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
+gitignore(5). 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
+gitignore(5). 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.<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.
+
+
+
+
LFSCONFIG
+
+
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:
+
+
+ - lfs.allowincompletepush
+ - lfs.fetchexclude
+ - lfs.fetchinclude
+ - lfs.gitprotocol
+ - lfs.locksverify
+ - lfs.pushurl
+ - lfs.skipdownloaderrors
+ - lfs.url
+ - lfs.{*}.access
+ - remote.{name}.lfsurl
+
+
+
The set of keys allowed in this file is restricted for security reasons.
+
+
EXAMPLES
+
+
+- Configure a custom LFS endpoint for your repository:
+
+
+
+
git config -f .lfsconfig lfs.url https://lfs.example.com/foo/bar/info/lfs
+
+
SEE ALSO
+
+
git-config(1), git-lfs-install(1), gitattributes(5), gitignore(5).
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-dedup(1)
+
+ - git-lfs-dedup(1)
+
+
+
+
+
NAME
+
+ git-lfs-dedup - Deduplicate Git LFS files
+
+
SYNOPSIS
+
+
git lfs dedup
+
+
DESCRIPTION
+
+
Deduplicates storage by re-creating working tree files as clones of the files in the Git LFS storage directory
+using the operating system's copy-on-write file creation functionality.
+
+
If the operating system or file system don't support copy-on-write file creation, this command exits unsuccessfully.
+
+
This command will also exit without success if any Git LFS extensions are
+configured, as these will typically be used to alter the file contents
+before they are written to the Git LFS storage directory, and therefore the
+working tree files should not be copy-on-write clones of the LFS object files.
+
+
SEE ALSO
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-env(1)
+
+ - git-lfs-env(1)
+
+
+
+
+
NAME
+
+ git-lfs-env - Display the Git LFS environment
+
+
SYNOPSIS
+
+
git lfs env
+
+
DESCRIPTION
+
+
Display the current Git LFS environment.
+
+
SEE ALSO
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-ext(1)
+
+ - git-lfs-ext(1)
+
+
+
+
+
NAME
+
+ git-lfs-ext - View extension details
+
+
SYNOPSIS
+
+
git lfs ext list [name...]
+
+
DESCRIPTION
+
+
Git LFS extensions enable the manipulation of files streams
+during smudge and clean.
+
+
EXAMPLES
+
+
+ -
+
List details for all extensions
+
+ git lfs ext
+ git lfs ext list
+
+ -
+
List details for the specified extensions
+
+ git lfs ext list 'foo' 'bar'
+
+
+
+
SEE ALSO
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-fetch(1)
+
+ - git-lfs-fetch(1)
+
+
+
+
+
NAME
+
+ git-lfs-fetch - Download all Git LFS files for a given ref
+
+
SYNOPSIS
+
+
git lfs fetch [options] [remote [ref...]]
+
+
DESCRIPTION
+
+
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.
+
+
OPTIONS
+
+
+-
+
-I paths --include=paths
+
+- Specify lfs.fetchinclude just for this invocation; see INCLUDE AND EXCLUDE
+
+-
+
-X paths --exclude=paths
+
+- Specify lfs.fetchexclude just for this invocation; see INCLUDE AND EXCLUDE
+
+--recent- Download objects referenced by recent branches & commits in addition to those
+that would otherwise be downloaded. See RECENT CHANGES
+
+--all- Download 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 -p
+
+- Prune old and unreferenced objects after fetching, equivalent to running
+
git lfs prune afterwards. See git-lfs-prune(1) for more details.
+
+
+
INCLUDE AND EXCLUDE
+
+
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 your Git configuration or in a .lfsconfig file, you may set either or
+both of lfs.fetchinclude and lfs.fetchexclude to comma-separated lists of
+paths. If lfs.fetchinclude is defined, Git LFS objects will only be fetched
+if their path matches one in that list, and if lfs.fetchexclude is defined,
+Git LFS objects will only be fetched if their path does not match one
+in that list. Paths are matched using wildcard matching as per gitignore(5).
+
+
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.
+
+
Examples
+
+
+ -
+
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.
+
+
+
+
DEFAULT REMOTE
+
+
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.
+
+
DEFAULT REFS
+
+
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.
+
+
RECENT CHANGES
+
+
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.
+
+
+
+
EXAMPLES
+
+
+ -
+
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
+
+
+
+
SEE ALSO
+
+
git-lfs-checkout(1), git-lfs-pull(1), git-lfs-prune(1), gitconfig(5).
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-filter-process(1)
+
+ - git-lfs-filter-process(1)
+
+
+
+
+
NAME
+
+ git-lfs-filter-process - Git filter process that converts between pointer and actual content
+
+
SYNOPSIS
+
+
git lfs filter-process
+git lfs filter-process --skip
+
+
DESCRIPTION
+
+
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.
+
+
In your Git configuration or in a .lfsconfig file, you may set either or
+both of lfs.fetchinclude and lfs.fetchexclude to comma-separated lists of
+paths. If lfs.fetchinclude is defined, Git LFS pointer files will only be
+replaced with the contents of the corresponding Git LFS object file if their
+path matches one in that list, and if lfs.fetchexclude is defined, Git LFS
+pointer files will only be replaced with the contents of the corresponding
+Git LFS object file if their path does not match one in that list. Paths are
+matched using wildcard matching as per gitignore(5). Git LFS pointer files
+that are not replaced with the contents of their corresponding object files
+are simply copied to standard output without change.
+
+
The filter process uses Git's pkt-line protocol to communicate, and is
+documented in detail in gitattributes(5).
+
+
OPTIONS
+
+
Without any options, filter-process accepts and responds to requests normally.
+
+
+--skip- Skip automatic downloading of objects on clone or pull.
+GIT_LFS_SKIP_SMUDGE- Disables the smudging process. For more, see: git-lfs-config(5).
+
+
+
SEE ALSO
+
+
git-lfs-clean(1), git-lfs-install(1), git-lfs-smudge(1), gitattributes(5), gitignore(5).
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-fsck(1)
+
+ - git-lfs-fsck(1)
+
+
+
+
+
NAME
+
+ git-lfs-fsck - Check GIT LFS files for consistency
+
+
SYNOPSIS
+
+
git lfs fsck [options] [revisions]
+
+
DESCRIPTION
+
+
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.
+
+
In your Git configuration or in a .lfsconfig file, you may set
+lfs.fetchexclude to a comma-separated list of paths. If lfs.fetchexclude
+is defined, then any Git LFS files whose paths match one in that list will
+not be checked for consistency. Paths are matched using wildcard matching as
+per gitignore(5).
+
+
OPTIONS
+
+
+--objects- Check that each object in HEAD matches its expected hash and that each object
+exists on disk.
+--pointers- Check that each pointer is canonical and that each file which should be stored
+as a Git LFS file is so stored.
+
+
+
SEE ALSO
+
+
git-lfs-ls-files(1), git-lfs-status(1), gitignore(5).
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-install(1)
+
+ - git-lfs-install(1)
+
+
+
+
+
NAME
+
+ git-lfs-install - Install Git LFS configuration.
+
+
SYNOPSIS
+
+
git lfs install options
+
+
DESCRIPTION
+
+
Perform the following actions to ensure that Git LFS is setup properly:
+
+
+ - Set up the clean and smudge filters under the name "lfs" in the global Git
+config.
+ - Install a pre-push hook to run git-lfs-pre-push(1) for the current repository,
+if run from inside one. If "core.hooksPath" is configured in any Git
+configuration (and supported, i.e., the installed Git version is at least
+2.9.0), then the pre-push hook will be installed to that directory instead.
+
+
+
OPTIONS
+
+
Without any options, git lfs install will only setup the "lfs" smudge and clean
+filters if they are not already set.
+
+
+--force- Sets the "lfs" smudge and clean filters, overwriting existing values.
+--local- Sets the "lfs" smudge and clean filters in the local repository's git
+ config, instead of the global git config (~/.gitconfig).
+--worktree- Sets the "lfs" smudge and clean filters in the current working tree's
+ git config, instead of the global git config (~/.gitconfig) or local
+ repository's git config ($GIT_DIR/config).
+ If multiple working trees are in use, the Git config extension
+
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.
+--manual- Print instructions for manually updating your hooks to include git-lfs
+ functionality. Use this option if
git lfs install fails because of existing
+ hooks and you want to retain their functionality.
+--system- Sets the "lfs" smudge and clean filters in the system git config, e.g. /etc/gitconfig
+ instead of the global git config (~/.gitconfig).
+--skip-smudge- Skips automatic downloading of objects on clone or pull. This requires a
+ manual "git lfs pull" every time a new commit is checked out on your
+ repository.
+--skip-repo- Skips setup of the local repo; use if you want to install the global lfs
+ filters but not make changes to the current repo.
+
+
+
SEE ALSO
+
+
git-lfs-uninstall(1), git-worktree(1).
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-lock(1)
+
+ - git-lfs-lock(1)
+
+
+
+
+
NAME
+
+ git-lfs-lock - Set a file as "locked" on the Git LFS server
+
+
SYNOPSIS
+
+
git lfs lock options path
+
+
DESCRIPTION
+
+
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.
+
+
OPTIONS
+
+
+-
+
-r name --remote=name
+
+- Specify the Git LFS server to use. Ignored if the
lfs.url config key is set.
+--json- Writes 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.
+
+
+
SEE ALSO
+
+
git-lfs-unlock(1), git-lfs-locks(1).
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-locks(1)
+
+ - git-lfs-locks(1)
+
+
+
+
+
NAME
+
+ git-lfs-locks - Lists currently locked files from the Git LFS server.
+
+
SYNOPSIS
+
+
git lfs locks options
+
+
DESCRIPTION
+
+
Lists current locks from the Git LFS server.
+
+
OPTIONS
+
+
+-
+
-r name --remote=name
+
+- Specify 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.
+--local- Lists only our own locks which are cached locally. Skips a remote call.
+--cached- Lists 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.
+--verify- Verifies 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.
+--json- Writes 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.
+
+
+
SEE ALSO
+
+
git-lfs-lock(1), git-lfs-unlock(1).
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-logs(1)
+
+ - git-lfs-logs(1)
+
+
+
+
+
NAME
+
+ git-lfs-logs - Show errors from the git-lfs command
+
+
SYNOPSIS
+
+
git lfs logs
+git lfs logs file
+git lfs logs clear
+git lfs logs boomtown
+
+
DESCRIPTION
+
+
Display errors from the git-lfs command. Any time it crashes, the details are
+saved to ".git/lfs/logs".
+
+
COMMANDS
+
+
+clear- Clears all of the existing logged errors.
+boomtown- Triggers a dummy exception.
+
+
+
OPTIONS
+
+
Without any options, git lfs logs simply shows the list of error logs.
+
+
+- file
+- Shows the specified error log. Use "last" to show the most recent error.
+
+
+
SEE ALSO
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-ls-files(1)
+
+ - git-lfs-ls-files(1)
+
+
+
+
+
NAME
+
+ git-lfs-ls-files - Show information about Git LFS files in the index and working tree
+
+
SYNOPSIS
+
+
git lfs ls-files [ref]
+git lfs ls-files ref ref
+
+
DESCRIPTION
+
+
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.
+
+
OPTIONS
+
+
+-
+
-l --long
+
+- Show the entire 64 character OID, instead of just first 10.
+-
+
-s --size
+
+- Show the size of the LFS object between parenthesis at the end of a line.
+-
+
-d --debug
+
+- Show as much information as possible about a LFS file. This is intended
+for manual inspection; the exact format may change at any time.
+-
+
-a --all
+
+- Inspects 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.
+--deleted- Shows the full history of the given reference, including objects that have
+been deleted.
+-
+
-I paths --include=paths
+
+- Include paths matching only these patterns; see [FETCH SETTINGS].
+-
+
-X paths --exclude=paths
+
+- Exclude paths matching any of these patterns; see [FETCH SETTINGS].
+-
+
-n --name-only
+
+- Show only the lfs tracked file names.
+## SEE ALSO
+
+
+
git-lfs-status(1), git-lfs-config(5).
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-merge-driver(1)
+
+ - git-lfs-merge-driver(1)
+
+
+
+
+
NAME
+
+ git-lfs-merge-driver - Merge text-based LFS files
+
+
SYNOPSIS
+
+
git lfs merge-driver options
+
+
DESCRIPTION
+
+
Merge text files stored in Git LFS using the default Git merge machinery, or a
+custom merge driver if specified. Note that this, in general, does not support
+partial renames or copies because Git does not support them in this case.
+
+
This program is intended to be invoked automatically by Git and not by users
+manually. See CONFIGURATION for details on the configuration required for
+that.
+
+
OPTIONS
+
+
+ -
+
--ancestor path
+Specify the file containing the ancestor revision.
+
+ -
+
--current path
+Specify the file containing the current revision.
+
+ -
+
--marker-size num
+Specify the conflict marker size as an integer.
+
+ -
+
--other path
+Specify the file containing the other revision.
+
+ -
+
--program program
+Specify a command, which is passed to the shell after substitution, that
+performs the actual merge. If this is not specified, git merge-file is
+invoked with appropriate arguments to perform the merge of the file.
+
+ See CONFIGURATION for the sequences which are substituted here.
+
+
+
+
CONFIGURATION
+
+
Git allows the use of a custom merge driver for files based on the merge
+attribute set in .gitattributes. By default, when using git lfs track, this
+value is set to lfs.
+
+
Because Git LFS can be used to store both text and binary files and it isn't
+always clear which behavior should be used, Git LFS does not enable this merge
+driver by default. However, if you know that some or all of your files are text
+files, then you can set the merge attribute for those files to lfs-text and
+use git config to set the merge driver like so:
+
+
console
+$ git config merge.lfs-text.driver 'git lfs merge-driver --ancestor %O --current %A --other %B --marker-size %L --output %A'
+
+
+
This tells Git to invoke the custom Git LFS merge driver, which in turn uses
+Git's merge machinery, to merge files where the merge attribute is set to
+lfs-text. Note that lfs-text here is an example and any syntactically valid
+value can be used.
+
+
If you are using a special type of file that needs rules different from Git's
+standard merge machinery, you can also specify the --program option, which
+is passed to sh after substituting its own percent-encoded escapes:
+
+
+ -
+
%A: the current version
+ -
+
%B: the other version
+ -
+
%D: the destination version
+ -
+
%O: the ancestor version
+ -
+
%L: the conflict marker size
+
+
+
Note that the percent sign must typically be doubled to prevent Git from
+substituting its own values here. Therefore, specifying the default behavior
+explicitly looks like this:
+
+
console
+$ git config merge.lfs-text.driver \
+ 'git lfs merge-driver --ancestor %O --current %A --other %B --marker-size %L --output %A --program '\''git merge-file --stdout --marker-size=%%L %%A %%O %%B >%%D'\'''
+
+
+
The exit status from the custom command should be zero on success or non-zero on
+conflicts or other failure.
+
+
Note that if no merge driver is specified for the value of the merge attribute
+(as is the case by default with merge=lfs), then the default Git merge
+strategy is used. For LFS files, this means that Git will try to merge the
+pointer files, which usually is not useful.
+
+
SEE ALSO
+
+
git-merge(1), git-merge-file(1), gitattributes(5)
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-migrate(1)
+
+ - git-lfs-migrate(1)
+
+
+
+
+
NAME
+
+ git-lfs-migrate - Migrate history to or from Git LFS
+
+
SYNOPSIS
+
+
git lfs migrate mode [options] [--] [branch ...]
+
+
DESCRIPTION
+
+
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 WITHOUT REWRITING HISTORY
+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 REFERENCES 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 .gitattributes files will always be assigned the default
+read/write permissions mode (i.e., without execute permissions). Any
+symbolic links with that name will cause the migration to halt prematurely.
+
+
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.
+
+
MODES
+
+
+
+
OPTIONS
+
+
+-
+
-I paths --include=paths
+
+- See INCLUDE AND EXCLUDE.
+-
+
-X paths --exclude=paths
+
+- See INCLUDE AND EXCLUDE.
+-
+
--include-ref=refname
+
+- See INCLUDE AND EXCLUDE REFERENCES.
+-
+
--exclude-ref=refname
+
+- See INCLUDE AND EXCLUDE REFERENCES.
+--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.
+--everything- See INCLUDE AND EXCLUDE REFERENCES.
+
+
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.
+
+--yes- Assume 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.
+- [branch ...]
+- 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.
+
+
+
+
INFO
+
+
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.
+
+
IMPORT
+
+
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. This option cannot be used with
+ the --include, --exclude, and --fixup options.
+
+ -
+
--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 WITHOUT REWRITING HISTORY.
+
+ -
+
--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.
+
+
IMPORT WITHOUT REWRITING 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.
+
+
EXPORT
+
+
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.
+
+
INCLUDE AND EXCLUDE
+
+
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.
+
+
Note that this form of pattern matching for the --include and --exclude
+options used by the git lfs migrate command is unique among the suite of
+git lfs commands. Other commands which also take these options, such as
+git lfs ls-files, use the gitignore(5) form of pattern matching instead.
+
+
INCLUDE AND EXCLUDE REFERENCES
+
+
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.
+
+
EXAMPLES
+
+
Migrate unpushed commits
+
+
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.
+
+
Migrate local history
+
+
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.
+
+
Migrate without rewriting local history
+
+
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
+
+
+
SEE ALSO
+
+
git-lfs-checkout(1), git-lfs-ls-files(1), git-lfs-track(1),
+git-lfs-untrack(1), gitattributes(5), gitignore(5).
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-pointer(1)
+
+ - git-lfs-pointer(1)
+
+
+
+
+
NAME
+
+ git-lfs-pointer - Build, compare, and check pointers
+
+
SYNOPSIS
+
+
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
+
+
Description
+
+
Builds and optionally compares generated pointer files to ensure consistency
+between different Git LFS implementations.
+
+
OPTIONS
+
+
+--file- A 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- In conjunction with
--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.
+
+
+
SEE ALSO
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-post-checkout(1)
+
+ - git-lfs-post-checkout(1)
+
+
+
+
+
NAME
+
+ git-lfs-post-checkout - Git post-checkout hook implementation
+
+
SYNOPSIS
+
+
git lfs post-checkout rev_before ref_after is_branch_checkout
+
+
DESCRIPTION
+
+
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.
+
+
SEE ALSO
+
+
git-lfs-track(1)
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-post-commit(1)
+
+ - git-lfs-post-commit(1)
+
+
+
+
+
NAME
+
+ git-lfs-post-commit - Git post-commit hook implementation
+
+
SYNOPSIS
+
+
git lfs post-commit
+
+
DESCRIPTION
+
+
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.
+
+
SEE ALSO
+
+
git-lfs-post-merge(1), git-lfs-track(1)
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-post-merge(1)
+
+ - git-lfs-post-merge(1)
+
+
+
+
+
NAME
+
+ git-lfs-post-merge - Git post-merge hook implementation
+
+
SYNOPSIS
+
+
git lfs post-merge is_squash
+
+
DESCRIPTION
+
+
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.
+
+
SEE ALSO
+
+
git-lfs-track(1)
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-pre-push(1)
+
+ - git-lfs-pre-push(1)
+
+
+
+
+
NAME
+
+ git-lfs-pre-push - Git pre-push hook implementation
+
+
SYNOPSIS
+
+
git lfs pre-push remote [remoteurl]
+
+
DESCRIPTION
+
+
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.
+
+
OPTIONS
+
+
+GIT_LFS_SKIP_PUSH- Do nothing on pre-push. For more, see: git-lfs-config(5).
+
+
+
SEE ALSO
+
+
git-lfs-clean(1), git-lfs-push(1).
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-prune(1)
+
+ - git-lfs-prune(1)
+
+
+
+
+
NAME
+
+ git-lfs-prune - Delete old LFS files from local storage
+
+
SYNOPSIS
+
+
git lfs prune options
+
+
DESCRIPTION
+
+
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:
+
+
+ - the current checkout
+ - all existing stashes
+ - a 'recent branch'; see RECENT FILES
+
+ - a 'recent commit' on the current branch or recent branches; see RECENT FILES
+
+ - a commit which has not been pushed; see UNPUSHED LFS FILES
+
+ - any other worktree checkouts; see git-worktree(1)
+
+
+
+
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(5) for more
+details about lfs.storage option.
+
+
In your Git configuration or in a .lfsconfig file, you may set
+lfs.fetchexclude to a comma-separated list of paths. If lfs.fetchexclude
+is defined, then any Git LFS files whose paths match one in that list will
+be pruned unless they are referenced by a stash or an unpushed commit.
+Paths are matched using wildcard matching as per gitignore(5).
+
+
OPTIONS
+
+
+ -
+
--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.
+
+
+
+
RECENT FILES
+
+
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.
+
+
+
+
UNPUSHED LFS FILES
+
+
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.
+
+
VERIFY REMOTE
+
+
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.
+
+
DEFAULT REMOTE
+
+
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'.
+
+
SEE ALSO
+
+
git-lfs-fetch(1), gitignore(5).
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-pull(1)
+
+ - git-lfs-pull(1)
+
+
+
+
+
NAME
+
+ git-lfs-pull - Download all Git LFS files for current ref & checkout
+
+
SYNOPSIS
+
+
git lfs pull [options] [remote]
+
+
DESCRIPTION
+
+
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
+
+
OPTIONS
+
+
+-
+
-I paths --include=paths
+
+- Specify lfs.fetchinclude just for this invocation; see INCLUDE AND EXCLUDE
+
+-
+
-X paths --exclude=paths
+
+- Specify lfs.fetchexclude just for this invocation; see INCLUDE AND EXCLUDE
+
+
+
+
INCLUDE AND EXCLUDE
+
+
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 your Git configuration or in a .lfsconfig file, you may set either or
+both of lfs.fetchinclude and lfs.fetchexclude to comma-separated lists of
+paths. If lfs.fetchinclude is defined, Git LFS objects will only be fetched
+if their path matches one in that list, and if lfs.fetchexclude is defined,
+Git LFS objects will only be fetched if their path does not match one
+in that list. Paths are matched using wildcard matching as per gitignore(5).
+
+
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.
+
+
DEFAULT REMOTE
+
+
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.
+
+
SEE ALSO
+
+
git-lfs-fetch(1), git-lfs-checkout(1), gitignore(5).
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-push(1)
+
+ - git-lfs-push(1)
+
+
+
+
+
NAME
+
+ git-lfs-push - Push queued large files to the Git LFS endpoint
+
+
SYNOPSIS
+
+
git lfs push options remote [ref...]
+git lfs push remote [ref...]
+git lfs push --object-id remote [oid...]
+
+
DESCRIPTION
+
+
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.
+
+
OPTIONS
+
+
+--dry-run- Print the files that would be pushed, without actually pushing them.
+--all- This 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 local refs are pushed. Note that this behavior differs from that of
+ git-lfs-fetch(1) when its
--all option is used; in that case, all refs
+ are fetched, including refs other than those under refs/heads and
+ refs/tags. If you are migrating a repository with these commands, make
+ sure to run git lfs push for any additional remote refs that contain
+ Git LFS objects not reachable from your local refs.
+--object-id- This pushes only the object OIDs listed at the end of the command, separated
+ by spaces.
+
+
+
SEE ALSO
+
+
git-lfs-fetch(1), git-lfs-pre-push(1).
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-smudge(1)
+
+ - git-lfs-smudge(1)
+
+
+
+
+
NAME
+
+ git-lfs-smudge - Git smudge filter that converts pointer in blobs to the actual content
+
+
SYNOPSIS
+
+
git lfs smudge [path]
+git lfs smudge --skip [path]
+
+
DESCRIPTION
+
+
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.
+
+
In your Git configuration or in a .lfsconfig file, you may set either or
+both of lfs.fetchinclude and lfs.fetchexclude to comma-separated lists of
+paths. If lfs.fetchinclude is defined, Git LFS pointer files will only be
+replaced with the contents of the corresponding Git LFS object file if their
+path matches one in that list, and if lfs.fetchexclude is defined, Git LFS
+pointer files will only be replaced with the contents of the corresponding
+Git LFS object file if their path does not match one in that list. Paths are
+matched using wildcard matching as per gitignore(5). Git LFS pointer files
+that are not replaced with the contents of their corresponding object files
+are simply copied to standard output without change.
+
+
OPTIONS
+
+
Without any options, git lfs smudge outputs the raw Git LFS content to
+standard output.
+
+
+--skip- Skip automatic downloading of objects on clone or pull.
+GIT_LFS_SKIP_SMUDGE- Disables the smudging process. For more, see: git-lfs-config(5).
+
+
+
KNOWN BUGS
+
+
On Windows, Git before 2.34.0 does not handle files in the working tree larger
+than 4 gigabytes. Newer versions of Git, as well as Unix versions, are
+unaffected.
+
+
SEE ALSO
+
+
git-lfs-install(1), gitattributes(5), gitignore(5).
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-standalone-file(1)
+
+ - git-lfs-standalone-file(1)
+
+
+
+
+
NAME
+
+ git-lfs-standalone-file - Standalone transfer adapter for file URLs
+
+
SYNOPSIS
+
+
git lfs standalone-file
+
+
DESCRIPTION
+
+
Provides a standalone transfer adapter for file URLs (local paths).
+
+
By default, Git LFS requires the support of an HTTP server to implement the Git
+LFS protocol. However, this tool allows the use of URLs starting with file:///
+(that is, those representing local paths) in addition. Configuration is not
+necessary; Git LFS handles this internally.
+
+
When invoked, this tool speaks JSON on input and output as a standalone transfer
+adapter. It is not intended for use by end users.
+
+
SEE ALSO
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-status(1)
+
+ - git-lfs-status(1)
+
+
+
+
+
NAME
+
+ git-lfs-status - Show the status of Git LFS files in the working tree
+
+
SYNOPSIS
+
+
git lfs status [options]
+
+
DESCRIPTION
+
+
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.
+
+
OPTIONS
+
+
+--porcelain- Give the output in an easy-to-parse format for scripts.
+--json- Give the output in a stable json format for scripts.
+
+
+
SEE ALSO
+
+
git-lfs-ls-files(1).
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-track(1)
+
+ - git-lfs-track(1)
+
+
+
+
+
NAME
+
+ git-lfs-track - View or add Git LFS paths to Git attributes
+
+
SYNOPSIS
+
+
git lfs track [options] [pattern...]
+
+
DESCRIPTION
+
+
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.
+
+
OPTIONS
+
+
+ -
+
--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).
+
+
+
+
EXAMPLES
+
+
+- List the patterns that Git LFS is currently tracking:
+
+
git lfs track
+
+
+- Configure Git LFS to track GIF files:
+
+
git lfs track "*.gif"
+
+
+- Configure Git LFS to track PSD files and make them read-only unless locked:
+
+
git lfs track --lockable "*.psd"
+
+
+- Configure Git LFS to track the file named
project [1].psd:
+
+ git lfs track --filename "project [1].psd"
+
+
+
+
+
SEE ALSO
+
+
git-lfs-untrack(1), git-lfs-install(1), gitattributes(5), gitignore(5).
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-uninstall(1)
+
+ - git-lfs-uninstall(1)
+
+
+
+
+
NAME
+
+ git-lfs-uninstall - Remove Git LFS configuration
+
+
SYNOPSIS
+
+
git lfs uninstall
+
+
DESCRIPTION
+
+
Perform the following actions to remove the Git LFS configuration:
+
+
+ - Remove the "lfs" clean and smudge filters from the global Git config.
+ - Uninstall the Git LFS pre-push hook if run from inside a Git repository.
+
+
+
OPTIONS
+
+
+- --local
+- Removes the "lfs" smudge and clean filters from the local repository's git
+ config, instead of the global git config (~/.gitconfig).
+- --worktree
+- Removes the "lfs" smudge and clean filters from the current working tree's
+ git config, instead of the global git config (~/.gitconfig) or local
+ repository's git config ($GIT_DIR/config).
+ If multiple working trees are in use, the Git config extension
+
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.
+- --system
+- Removes the "lfs" smudge and clean filters from the system git config,
+ instead of the global git config (~/.gitconfig).
+- --skip-repo
+- Skips cleanup of the local repo; use if you want to uninstall the global lfs
+ filters but not make changes to the current repo.
+
+
+
SEE ALSO
+
+
git-lfs-install(1), git-worktree(1).
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-unlock(1)
+
+ - git-lfs-unlock(1)
+
+
+
+
+
NAME
+
+ git-lfs-unlock - Remove "locked" setting for a file on the Git LFS server
+
+
SYNOPSIS
+
+
git lfs unlock OPTIONS path
+
+
DESCRIPTION
+
+
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.
+
+
OPTIONS
+
+
+-
+
-r name --remote=name
+
+- Specify the Git LFS server to use. Ignored if the
lfs.url config key is set.
+-
+
-f --force
+
+- Tells 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.
+--json- Writes 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.
+
+
+
SEE ALSO
+
+
git-lfs-lock(1), git-lfs-locks(1).
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-untrack(1)
+
+ - git-lfs-untrack(1)
+
+
+
+
+
NAME
+
+ git-lfs-untrack - Remove Git LFS paths from Git Attributes
+
+
SYNOPSIS
+
+
git lfs untrack path...
+
+
DESCRIPTION
+
+
Stop tracking the given path(s) through Git LFS. The path argument
+can be a glob pattern or a file path.
+
+
EXAMPLES
+
+
+- Configure Git LFS to stop tracking GIF files:
+
+
git lfs untrack "*.gif"
+
+
+
+
+
SEE ALSO
+
+
git-lfs-track(1), git-lfs-install(1), gitattributes(5).
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs-update(1)
+
+ - git-lfs-update(1)
+
+
+
+
+
NAME
+
+ git-lfs-update - Update Git hooks
+
+
SYNOPSIS
+
+
+
+
+
+git lfs update [--manual |
+ --force] |
+
+
+
+
+
DESCRIPTION
+
+
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.
+
+
OPTIONS
+
+
+ -
+
--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.
+
+
+
+
SEE ALSO
+
+
Part of the git-lfs(1) suite.
+
+
+
+
+
+
+
+
+ - git-lfs(1)
+
+ - git-lfs(1)
+
+
+
+
+
NAME
+
+ git-lfs - Work with large files in Git repositories
+
+
SYNOPSIS
+
+
git lfs command [args]
+
+
DESCRIPTION
+
+
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.
+
+
COMMANDS
+
+
Like Git, Git LFS commands are separated into high level ("porcelain")
+commands and low level ("plumbing") commands.
+
+
High level porcelain commands
+
+
+- git-lfs-checkout(1)
+- Populate working copy with real content from Git LFS files.
+- git-lfs-dedup(1)
+- De-duplicate Git LFS files.
+- git-lfs-env(1)
+- Display the Git LFS environment.
+- git-lfs-ext(1)
+- Display Git LFS extension details.
+- git-lfs-fetch(1)
+- Download Git LFS files from a remote.
+- git-lfs-fsck(1)
+- Check Git LFS files for consistency.
+- git-lfs-install(1)
+- Install Git LFS configuration.
+- git-lfs-lock(1)
+- Set a file as "locked" on the Git LFS server.
+- git-lfs-locks(1)
+- List currently "locked" files from the Git LFS server.
+- git-lfs-logs(1)
+- Show errors from the Git LFS command.
+- git-lfs-ls-files(1)
+- Show information about Git LFS files in the index and working tree.
+- git-lfs-migrate(1)
+- Migrate history to or from Git LFS
+- git-lfs-prune(1)
+- Delete old Git LFS files from local storage
+- git-lfs-pull(1)
+- Fetch Git LFS changes from the remote & checkout any required working tree
+ files.
+- git-lfs-push(1)
+- Push queued large files to the Git LFS endpoint.
+- git-lfs-status(1)
+- Show the status of Git LFS files in the working tree.
+- git-lfs-track(1)
+- View or add Git LFS paths to Git attributes.
+- git-lfs-uninstall(1)
+- Uninstall Git LFS by removing hooks and smudge/clean filter configuration.
+- git-lfs-unlock(1)
+- Remove "locked" setting for a file on the Git LFS server.
+- git-lfs-untrack(1)
+- Remove Git LFS paths from Git Attributes.
+- git-lfs-update(1)
+- Update Git hooks for the current Git repository.
+- git-lfs-version(1)
+- Report the version number.
+
+
+
Low level plumbing commands
+
+
+- git-lfs-clean(1)
+- Git clean filter that converts large files to pointers.
+- git-lfs-filter-process(1)
+- Git process filter that converts between large files and pointers.
+- git-lfs-merge-driver(1)
+- Merge text-based LFS files
+- git-lfs-pointer(1)
+- Build and compare pointers.
+- git-lfs-post-checkout(1)
+- Git post-checkout hook implementation.
+- git-lfs-post-commit(1)
+- Git post-commit hook implementation.
+- git-lfs-post-merge(1)
+- Git post-merge hook implementation.
+- git-lfs-pre-push(1)
+- Git pre-push hook implementation.
+- git-lfs-smudge(1)
+- Git smudge filter that converts pointer in blobs to the actual content.
+- git-lfs-standalone-file(1)
+- Git LFS standalone transfer adapter for file URLs (local paths).
+
+
+
EXAMPLES
+
+
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 needs 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
+
+
+
+
+
+
+
",
+ "lstrip": false,
+ "normalized": false,
+ "rstrip": false,
+ "single_word": false
+ },
+ "eos_token": {
+ "content": "",
+ "lstrip": false,
+ "normalized": false,
+ "rstrip": false,
+ "single_word": false
+ },
+ "pad_token": "",
+ "unk_token": {
+ "content": "",
+ "lstrip": false,
+ "normalized": false,
+ "rstrip": false,
+ "single_word": false
+ }
+}
diff --git a/tokenizer.model b/tokenizer.model
new file mode 100644
index 0000000000000000000000000000000000000000..8b443ef19c2a19acc3ac64fb9c3db4a72921dff6
--- /dev/null
+++ b/tokenizer.model
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:dadfd56d766715c61d2ef780a525ab43b8e6da4de6865bda3d95fdef5e134055
+size 493443
diff --git a/tokenizer_config.json b/tokenizer_config.json
new file mode 100644
index 0000000000000000000000000000000000000000..a583d0f8c569fedb4f95590b442b2ac9f5fbd0bf
--- /dev/null
+++ b/tokenizer_config.json
@@ -0,0 +1,45 @@
+{
+ "add_bos_token": true,
+ "add_eos_token": false,
+ "add_prefix_space": true,
+ "added_tokens_decoder": {
+ "0": {
+ "content": "",
+ "lstrip": false,
+ "normalized": false,
+ "rstrip": false,
+ "single_word": false,
+ "special": true
+ },
+ "1": {
+ "content": "",
+ "lstrip": false,
+ "normalized": false,
+ "rstrip": false,
+ "single_word": false,
+ "special": true
+ },
+ "2": {
+ "content": "",
+ "lstrip": false,
+ "normalized": false,
+ "rstrip": false,
+ "single_word": false,
+ "special": true
+ }
+ },
+ "additional_special_tokens": [],
+ "bos_token": "",
+ "chat_template": "{{ bos_token }}{% for message in messages %}{% if (message['role'] == 'user') != (loop.index0 % 2 == 0) %}{{ raise_exception('Conversation roles must alternate user/assistant/user/assistant/...') }}{% endif %}{% if message['role'] == 'user' %}{{ '[INST] ' + message['content'] + ' [/INST]' }}{% elif message['role'] == 'assistant' %}{{ message['content'] + eos_token}}{% else %}{{ raise_exception('Only user and assistant roles are supported!') }}{% endif %}{% endfor %}",
+ "clean_up_tokenization_spaces": false,
+ "eos_token": "",
+ "legacy": true,
+ "model_max_length": 1000000000000000019884624838656,
+ "pad_token": "",
+ "sp_model_kwargs": {},
+ "spaces_between_special_tokens": false,
+ "tokenizer_class": "LlamaTokenizer",
+ "unk_token": "",
+ "use_default_system_prompt": false,
+ "use_fast": true
+}