I'm experiencing an issue with pushing several video files tracked with LFS to a Bitbucket origin under versions 2.0.0 and 2.0.1. Everything works fine when I downgrade to v1.5.6.
In detail, I have a videos/
directory in my repo with a number of files, ranging from 7 to 90 MB, in .webm, .mp4, .swf, .ogg, and .flv formats. I can commit locally without issue, and git lfs is happily tracking videos/*
. On git push
with 2.0.x I get the following printout:
$ git push
Remote "origin" does not support the LFS locking API. Consider disabling it with:
$ git config 'lfs.https://bitbucket/telstarevents/saratoga.git/info/lfs.locksverify' false
Git LFS: (0 of 10 files) 85.69 MB / 338.78 MB panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x38 pc=0x13017bc]
goroutine 85 [running]:
github.com/git-lfs/git-lfs/tq.verifyUpload(0xc42010e300, 0xc4203ec900, 0xc420412440, 0x40)
/private/tmp/git-lfs-20170307-63219-522lj3/git-lfs-2.0.1/src/github.com/git-lfs/git-lfs/tq/verify.go:43 +0x28c
github.com/git-lfs/git-lfs/tq.(*customAdapter).DoTransfer(0xc4204128c0, 0x13e1a40, 0xc420412ac0, 0xc4203ec900, 0xc420480d20, 0xc42050a8a0, 0x0, 0x0)
/private/tmp/git-lfs-20170307-63219-522lj3/git-lfs-2.0.1/src/github.com/git-lfs/git-lfs/tq/custom.go:320 +0x71e
github.com/git-lfs/git-lfs/tq.(*adapterBase).worker(0xc42011ed00, 0x0, 0x13e1a40, 0xc420412ac0)
/private/tmp/git-lfs-20170307-63219-522lj3/git-lfs-2.0.1/src/github.com/git-lfs/git-lfs/tq/adapterbase.go:162 +0x5cb
created by github.com/git-lfs/git-lfs/tq.(*adapterBase).Begin
/private/tmp/git-lfs-20170307-63219-522lj3/git-lfs-2.0.1/src/github.com/git-lfs/git-lfs/tq/adapterbase.go:82 +0x2de
error: failed to push some refs to 'git@bitbucket:telstarevents/saratoga.git'
(I've repeatedly disabled the LFS locking API as prompted at the top; warning doesn't go away. On 1.5.6 there is no warning.)
As you can see, the upload starts and then fails partway through.
Here's the printout of git lfs env
for my 2.0.1 environment:
git-lfs/2.0.1 (GitHub; darwin amd64; go 1.8)
git version 2.12.0
LocalWorkingDir=
LocalGitDir=
LocalGitStorageDir=
LocalMediaDir=
LocalReferenceDir=
TempDir=/var/folders/mj/dgqrcpfj5vg4khjv0bg4jv9r0000gn/T/git-lfs
ConcurrentTransfers=3
TusTransfers=false
BasicTransfersOnly=false
SkipDownloadErrors=false
FetchRecentAlways=false
FetchRecentRefsDays=7
FetchRecentCommitsDays=0
FetchRecentRefsIncludeRemotes=true
PruneOffsetDays=3
PruneVerifyRemoteAlways=false
PruneRemoteName=origin
AccessDownload=none
AccessUpload=none
DownloadTransfers=basic,bitbucket-media-api
UploadTransfers=basic,bitbucket-media-api
git config filter.lfs.process = "git-lfs filter-process"
git config filter.lfs.smudge = "git-lfs smudge – %f"
git config filter.lfs.clean = "git-lfs clean – %f"
Machine is running OSX 10.11.6.
I should note that I was able to push other files (fonts and images) under LFS without issue, it just seems to be the video files that trigger the bug. I got the Remote "origin" does not support the LFS locking API. Consider disabling it...
warning for everything, but that apparently didn't break pushing.
Hi @andronocean, thanks for opening this and sorry that you're having trouble. That stack trace makes it look like the lfsapi.Client.GitEnv()
was returning nil
, which I have discovered is the case when using a custom
adapter[1]:
} else if a.direction == Upload {
cli := &lfsapi.Client{}
if err = verifyUpload(cli, t); err != nil {
return err
}
}
I went ahead and fixed this in https://github.com/git-lfs/git-lfs/pull/2047.
@andronocean I just merged #2047 into master
, but I think we're going to hold off on a patch release for a little while. In the meantime, you can either:
master
branch) by following the build instructions in the README.git config lfs.basictransfersonly true
.
Most helpful comment
@andronocean I just merged #2047 into
master
, but I think we're going to hold off on a patch release for a little while. In the meantime, you can either:master
branch) by following the build instructions in the README.git config lfs.basictransfersonly true
.