On 8 December 2016 at 14:18, Lars Schneider <larsxschneider@xxxxxxxxx> wrote: > >> On 08 Dec 2016, at 15:00, Nick Warr <nick.warr@xxxxxxxxxxxxxxxx> wrote: >> >> That looks pretty much like the error we're dealing with, any reason >> why going back a point version on Git (not git-lfs) would resolve the >> issue however? > > Going back to GitLFS 1.4.* would make the error disappear. However, I think > you should fix your repository. Try this: > > git lfs clone <YOUR REPO URL> > cd <YOUR REPO> > git rm --cached "workers/unity/Assets/3rdPartyAssets/FORGE3D/Sci-Fi Effects/Effects/Debris/Meshes/debris_junk.FBX" > git add --force "workers/unity/Assets/3rdPartyAssets/FORGE3D/Sci-Fi Effects/Effects/Debris/Meshes/debris_junk.FBX" > git commit -m "Move files properly to GitLFS" > git push > > Afterwards you should be able to use the latest version of Git and GitLFS > without trouble. > > Cheers, > Lars > > PS: Top posting is not that popular in the Git community ;-) > > >> >> On 8 December 2016 at 13:57, Lars Schneider <larsxschneider@xxxxxxxxx> wrote: >>> >>>> On 08 Dec 2016, at 12:46, Nick Warr <nick.warr@xxxxxxxxxxxxxxxx> wrote: >>>> >>>> Using Git-2.11.0 with the latest git-lfs 1.5.2 (also tested with >>>> 1.5.3) cloning from our locally hosted gitlab CE server via HTTPS. >>>> >>>> When cloning a repo (large, 3.3 gig in git, 10.3 in LFS) for the >>>> first time the clone will finish the checkout of the git part, then >>>> when it starts downloading the LFS parts it will reliably finish with >>>> a smudge filter error. >>>> >>>> This leaves the repo in an unstable condition, you can then fetch the >>>> lfs part without issue, but checking out the lfs files or trying a git >>>> reset --hard will continue to spit out the same error. As you can see, >>>> the actual error is not particularly useful. >>>> >>>> fatal: workers/unity/Assets/3rdPartyAssets/FORGE3D/Sci-Fi >>>> Effects/Effects/Debris/Meshes/debris_junk.FBX: smudge filter lfs >>>> failed >>>> Unknown command "" >>>> >>>> Possibly it's due to the file extension being all capital letters, we >>>> did manage to change the error by recommitting the file with a >>>> lowercase extension, but it failed on the next file (which also had a >>>> capital letter extension). >>>> >>>> This has happened on multiple fresh windows 10 64 bit installs, >>>> different machines and target directories (to hopefully remove the >>>> possibility of file permissions) where cloning is taking place. >>>> >>>> The solution is to back level to Git 2.10.2 and the error disappears. >>>> >>>> More than willing to provide any further information, >>> >>> Hi Nick, >>> >>> debris_junk.FBX is not stored properly in Git LFS. >>> I explained the problem in detail here: >>> https://github.com/git-lfs/git-lfs/issues/1729 >>> >>> You should add the file properly to GitLFS to fix the problem. >>> However, I think this is a regression in GitLFS and I hope it will >>> be fixed in the next version. >>> >>> No change/fix in Git is required. >>> >>> Cheers, >>> Lars > Thank gmail for the top posting, hard enough getting it to send non html mail :( Just to add a bit more to the discussion, we went and had a look at that directory which was freshly cloned with 2.10.2 and 1.5.3 and the files were there (400 KB + FBX files, not 2KB pointers) after the git reset --hard, we're actually looking at renaming all those files, as that isn't the only one unfortunately..