Git LFS 2.1.0 released

Today we’re announcing the next major release of Git LFS: v2.1.0, including new features, performance improvements, and more.

New features

Status subcommand

With Git LFS 2.1.0, get a more comprehensive look at which files are marked as modified by running the git lfs status command.

Git LFS will now tell you if your large files are being tracked by LFS, stored by Git, or a combination of both. For instance, if LFS sees a file that is stored as a large object in Git, it will convert it to an LFS pointer on checkout which will mark the file as modified. To diagnose this, try git lfs status for a look at what’s going on:

On branch master

Git LFS objects to be committed:

converted-lfs-file.dat (Git: acfe112 -> LFS: acfe112)
new-lfs-file.dat (LFS: eeaf82b)
partially-staged-lfs-file.dat (LFS: a12942e)

Git LFS objects not staged for commit:

unstaged-lfs-file.dat (LFS: 1307990 -> File: 8735179)
partially-staged-lfs-file.dat (File: 0dc8537)

Per-server configuration

Git LFS 2.1.0 introduces support for URL-style configuration via your .gitconfig or .lfsconfig. For settings that apply to URLs, like http.sslCert or lfs.locksverify, you can now scope them to a top-level domain, a root path, or just about anything else.

Network debugging tools

To better understand and debug network requests made by Git LFS, version 2.1.0 introduces a detailed view via the GIT_LOG_STATS=1 environment variable:

$ GIT_LOG_STATS=1 git lfs pull
Git LFS: (201 of 201 files) 1.17 GB / 1.17 GB

$ cat .git/lfs/objects/logs/http/*.log
concurrent=15 time=1493330448 version=git-lfs/2.1.0 (GitHub; darwin amd64; go 1.8.1; git f9d0c49e)
key=lfs.batch event=request url=https://github.com/user/repo.git/info/lfs/objects/batch method=POST body=8468
key=lfs.batch event=request url=https://github.com/user/repo.git/info/lfs/objects/batch method=POST status=200 body=59345 conntime=47448309 dnstime=2222176 tlstime=163385183 time=491626933
key=lfs.data.download event=request url=https://github-cloud.s3.amazonaws.com/... method=GET status=200 body=4 conntime=58735013 dnstime=6486563 tlstime=120484526 time=258568133
key=lfs.data.download event=request url=https://github-cloud.s3.amazonaws.com/... method=GET status=200 body=4 conntime=58231460 dnstime=6417657 tlstime=122486379 time=261003305

# ...

Relative object expiration

The Git LFS API has long supported an expires_at property in both SSH authenticate as well as Batch API responses. This introduced a number of issues where an out-of-sync system clock would cause LFS to think that objects were expired when they were still valid. Git LFS 2.1.0 now supports an expires_in property to specify a duration relative to your computer’s time to expire the object.

What’s next?

The LFS team is working on a migration tool to easily migrate your existing Git repositories with large objects into LFS without the need to write a git filter-branch command. We’re also still inviting your feedback on our File Locking feature.

In addition, our roadmap is public: comments, questions, and pull requests are welcomed. To learn more about Git LFS, visit the Git LFS website.

That was a quick overview of some of the larger changes included in this release. To get a more detailed look, check out the release notes.

Written by

Taylor Blau

@ttaylorr

Taylor Blau is a Staff Software Engineer at GitHub where he works on Git.