Today we’re announcing the next major release of Git LFS: v2.1.0, including new features, performance improvements, and more.
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)
Git LFS 2.1.0 introduces support for URL-style configuration via your
.lfsconfig. For settings that apply to URLs, like
lfs.locksverify, you can now scope them to a top-level domain, a root path, or just about anything else.
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 # ...
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.
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.
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.