{"thread":{"id":"44651","subject":"Serious bug with Git-2.11.0-64-bit and Git-LFS","startedAt":"2016-12-08T11:46:36Z","lastAt":"2016-12-08T15:37:11Z","messageCount":5,"participants":["Nick Warr","Lars Schneider"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"307237","messageId":"CABW+60x0PSw7uNQZg4SeN7EAbNpraR_HWvnVFz1-fVLYX=B8RQ@mail.gmail.com","threadId":"44651","inReplyTo":null,"subject":"Serious bug with Git-2.11.0-64-bit and Git-LFS","fromName":"Nick Warr","fromEmail":"nick.warr@bossastudios.com","sentAt":"2016-12-08T11:46:28Z","receivedAt":"2016-12-08T11:46:36Z","isPatch":false,"sender":{"key":"nick.warr@bossastudios.com","avatar":null},"body":"Using Git-2.11.0 with the latest git-lfs 1.5.2 (also tested with\n1.5.3) cloning from our locally hosted gitlab CE server via HTTPS.\n\n When cloning a repo (large, 3.3 gig in git, 10.3 in LFS)  for the\nfirst time the clone will finish the checkout of the git part, then\nwhen it starts downloading the LFS parts it will reliably finish with\na smudge filter error.\n\n This leaves the repo in an unstable condition, you can then fetch the\nlfs part without issue, but checking out the lfs files or trying a git\nreset --hard will continue to spit out the same error. As you can see,\nthe actual error is not particularly useful.\n\nfatal: workers/unity/Assets/3rdPartyAssets/FORGE3D/Sci-Fi\nEffects/Effects/Debris/Meshes/debris_junk.FBX: smudge filter lfs\nfailed\nUnknown command \"\"\n\nPossibly it's due to the file extension being all capital letters, we\ndid manage to change the error by recommitting the file with a\nlowercase extension, but it failed on the next file (which also had a\ncapital letter extension).\n\n This has happened on multiple fresh windows 10 64 bit installs,\ndifferent machines and target directories (to hopefully remove the\npossibility of file permissions) where cloning is taking place.\n\nThe solution is to back level to Git 2.10.2 and the error disappears.\n\nMore than willing to provide any further information,\n\nNick Warr\n"},{"id":"307240","messageId":"06520F42-BD49-4349-83B3-74DCA1E260CD@gmail.com","threadId":"44651","inReplyTo":"CABW+60x0PSw7uNQZg4SeN7EAbNpraR_HWvnVFz1-fVLYX=B8RQ@mail.gmail.com","subject":"Re: Serious bug with Git-2.11.0-64-bit and Git-LFS","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-12-08T13:57:57Z","receivedAt":"2016-12-08T13:57:53Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 08 Dec 2016, at 12:46, Nick Warr <nick.warr@bossastudios.com> wrote:\n> \n> Using Git-2.11.0 with the latest git-lfs 1.5.2 (also tested with\n> 1.5.3) cloning from our locally hosted gitlab CE server via HTTPS.\n> \n> When cloning a repo (large, 3.3 gig in git, 10.3 in LFS)  for the\n> first time the clone will finish the checkout of the git part, then\n> when it starts downloading the LFS parts it will reliably finish with\n> a smudge filter error.\n> \n> This leaves the repo in an unstable condition, you can then fetch the\n> lfs part without issue, but checking out the lfs files or trying a git\n> reset --hard will continue to spit out the same error. As you can see,\n> the actual error is not particularly useful.\n> \n> fatal: workers/unity/Assets/3rdPartyAssets/FORGE3D/Sci-Fi\n> Effects/Effects/Debris/Meshes/debris_junk.FBX: smudge filter lfs\n> failed\n> Unknown command \"\"\n> \n> Possibly it's due to the file extension being all capital letters, we\n> did manage to change the error by recommitting the file with a\n> lowercase extension, but it failed on the next file (which also had a\n> capital letter extension).\n> \n> This has happened on multiple fresh windows 10 64 bit installs,\n> different machines and target directories (to hopefully remove the\n> possibility of file permissions) where cloning is taking place.\n> \n> The solution is to back level to Git 2.10.2 and the error disappears.\n> \n> More than willing to provide any further information,\n\nHi Nick,\n\ndebris_junk.FBX is not stored properly in Git LFS.\nI explained the problem in detail here: \nhttps://github.com/git-lfs/git-lfs/issues/1729\n\nYou should add the file properly to GitLFS to fix the problem.\nHowever, I think this is a regression in GitLFS and I hope it will \nbe fixed in the next version.\n\nNo change/fix in Git is required.\n\nCheers,\nLars\n"},{"id":"307241","messageId":"CABW+60za0shXucPgg_jGYt4f8QbkLzLmS5GRf8czE67Taqd+zw@mail.gmail.com","threadId":"44651","inReplyTo":"06520F42-BD49-4349-83B3-74DCA1E260CD@gmail.com","subject":"Re: Serious bug with Git-2.11.0-64-bit and Git-LFS","fromName":"Nick Warr","fromEmail":"nick.warr@bossastudios.com","sentAt":"2016-12-08T14:00:34Z","receivedAt":"2016-12-08T14:00:42Z","isPatch":false,"sender":{"key":"nick.warr@bossastudios.com","avatar":null},"body":"That looks pretty much like the error we're dealing with, any reason\nwhy going back a point version on Git (not git-lfs) would resolve the\nissue however?\n\nOn 8 December 2016 at 13:57, Lars Schneider <larsxschneider@gmail.com> wrote:\n>\n>> On 08 Dec 2016, at 12:46, Nick Warr <nick.warr@bossastudios.com> wrote:\n>>\n>> Using Git-2.11.0 with the latest git-lfs 1.5.2 (also tested with\n>> 1.5.3) cloning from our locally hosted gitlab CE server via HTTPS.\n>>\n>> When cloning a repo (large, 3.3 gig in git, 10.3 in LFS)  for the\n>> first time the clone will finish the checkout of the git part, then\n>> when it starts downloading the LFS parts it will reliably finish with\n>> a smudge filter error.\n>>\n>> This leaves the repo in an unstable condition, you can then fetch the\n>> lfs part without issue, but checking out the lfs files or trying a git\n>> reset --hard will continue to spit out the same error. As you can see,\n>> the actual error is not particularly useful.\n>>\n>> fatal: workers/unity/Assets/3rdPartyAssets/FORGE3D/Sci-Fi\n>> Effects/Effects/Debris/Meshes/debris_junk.FBX: smudge filter lfs\n>> failed\n>> Unknown command \"\"\n>>\n>> Possibly it's due to the file extension being all capital letters, we\n>> did manage to change the error by recommitting the file with a\n>> lowercase extension, but it failed on the next file (which also had a\n>> capital letter extension).\n>>\n>> This has happened on multiple fresh windows 10 64 bit installs,\n>> different machines and target directories (to hopefully remove the\n>> possibility of file permissions) where cloning is taking place.\n>>\n>> The solution is to back level to Git 2.10.2 and the error disappears.\n>>\n>> More than willing to provide any further information,\n>\n> Hi Nick,\n>\n> debris_junk.FBX is not stored properly in Git LFS.\n> I explained the problem in detail here:\n> https://github.com/git-lfs/git-lfs/issues/1729\n>\n> You should add the file properly to GitLFS to fix the problem.\n> However, I think this is a regression in GitLFS and I hope it will\n> be fixed in the next version.\n>\n> No change/fix in Git is required.\n>\n> Cheers,\n> Lars\n"},{"id":"307250","messageId":"D1437EA2-F4D3-4190-8D79-020C06CFA3DB@gmail.com","threadId":"44651","inReplyTo":"CABW+60za0shXucPgg_jGYt4f8QbkLzLmS5GRf8czE67Taqd+zw@mail.gmail.com","subject":"Re: Serious bug with Git-2.11.0-64-bit and Git-LFS","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-12-08T14:18:30Z","receivedAt":"2016-12-08T14:33:20Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 08 Dec 2016, at 15:00, Nick Warr <nick.warr@bossastudios.com> wrote:\n> \n> That looks pretty much like the error we're dealing with, any reason\n> why going back a point version on Git (not git-lfs) would resolve the\n> issue however?\n\nGoing back to GitLFS 1.4.* would make the error disappear. However, I think\nyou should fix your repository. Try this:\n\ngit lfs clone <YOUR REPO URL>\ncd <YOUR REPO>\ngit rm --cached \"workers/unity/Assets/3rdPartyAssets/FORGE3D/Sci-Fi Effects/Effects/Debris/Meshes/debris_junk.FBX\"\ngit add --force \"workers/unity/Assets/3rdPartyAssets/FORGE3D/Sci-Fi Effects/Effects/Debris/Meshes/debris_junk.FBX\"\ngit commit -m \"Move files properly to GitLFS\"\ngit push\n\nAfterwards you should be able to use the latest version of Git and GitLFS\nwithout trouble.\n\nCheers,\nLars\n\nPS: Top posting is not that popular in the Git community ;-)\n\n\n> \n> On 8 December 2016 at 13:57, Lars Schneider <larsxschneider@gmail.com> wrote:\n>> \n>>> On 08 Dec 2016, at 12:46, Nick Warr <nick.warr@bossastudios.com> wrote:\n>>> \n>>> Using Git-2.11.0 with the latest git-lfs 1.5.2 (also tested with\n>>> 1.5.3) cloning from our locally hosted gitlab CE server via HTTPS.\n>>> \n>>> When cloning a repo (large, 3.3 gig in git, 10.3 in LFS)  for the\n>>> first time the clone will finish the checkout of the git part, then\n>>> when it starts downloading the LFS parts it will reliably finish with\n>>> a smudge filter error.\n>>> \n>>> This leaves the repo in an unstable condition, you can then fetch the\n>>> lfs part without issue, but checking out the lfs files or trying a git\n>>> reset --hard will continue to spit out the same error. As you can see,\n>>> the actual error is not particularly useful.\n>>> \n>>> fatal: workers/unity/Assets/3rdPartyAssets/FORGE3D/Sci-Fi\n>>> Effects/Effects/Debris/Meshes/debris_junk.FBX: smudge filter lfs\n>>> failed\n>>> Unknown command \"\"\n>>> \n>>> Possibly it's due to the file extension being all capital letters, we\n>>> did manage to change the error by recommitting the file with a\n>>> lowercase extension, but it failed on the next file (which also had a\n>>> capital letter extension).\n>>> \n>>> This has happened on multiple fresh windows 10 64 bit installs,\n>>> different machines and target directories (to hopefully remove the\n>>> possibility of file permissions) where cloning is taking place.\n>>> \n>>> The solution is to back level to Git 2.10.2 and the error disappears.\n>>> \n>>> More than willing to provide any further information,\n>> \n>> Hi Nick,\n>> \n>> debris_junk.FBX is not stored properly in Git LFS.\n>> I explained the problem in detail here:\n>> https://github.com/git-lfs/git-lfs/issues/1729\n>> \n>> You should add the file properly to GitLFS to fix the problem.\n>> However, I think this is a regression in GitLFS and I hope it will\n>> be fixed in the next version.\n>> \n>> No change/fix in Git is required.\n>> \n>> Cheers,\n>> Lars\n\n"},{"id":"307260","messageId":"CABW+60whExoSLGJSQBbUREC31MCO+c0Vps9Ouc24DF==UrAF4g@mail.gmail.com","threadId":"44651","inReplyTo":"D1437EA2-F4D3-4190-8D79-020C06CFA3DB@gmail.com","subject":"Re: Serious bug with Git-2.11.0-64-bit and Git-LFS","fromName":"Nick Warr","fromEmail":"nick.warr@bossastudios.com","sentAt":"2016-12-08T15:36:41Z","receivedAt":"2016-12-08T15:37:11Z","isPatch":false,"sender":{"key":"nick.warr@bossastudios.com","avatar":null},"body":"On 8 December 2016 at 14:18, Lars Schneider <larsxschneider@gmail.com> wrote:\n>\n>> On 08 Dec 2016, at 15:00, Nick Warr <nick.warr@bossastudios.com> wrote:\n>>\n>> That looks pretty much like the error we're dealing with, any reason\n>> why going back a point version on Git (not git-lfs) would resolve the\n>> issue however?\n>\n> Going back to GitLFS 1.4.* would make the error disappear. However, I think\n> you should fix your repository. Try this:\n>\n> git lfs clone <YOUR REPO URL>\n> cd <YOUR REPO>\n> git rm --cached \"workers/unity/Assets/3rdPartyAssets/FORGE3D/Sci-Fi Effects/Effects/Debris/Meshes/debris_junk.FBX\"\n> git add --force \"workers/unity/Assets/3rdPartyAssets/FORGE3D/Sci-Fi Effects/Effects/Debris/Meshes/debris_junk.FBX\"\n> git commit -m \"Move files properly to GitLFS\"\n> git push\n>\n> Afterwards you should be able to use the latest version of Git and GitLFS\n> without trouble.\n>\n> Cheers,\n> Lars\n>\n> PS: Top posting is not that popular in the Git community ;-)\n>\n>\n>>\n>> On 8 December 2016 at 13:57, Lars Schneider <larsxschneider@gmail.com> wrote:\n>>>\n>>>> On 08 Dec 2016, at 12:46, Nick Warr <nick.warr@bossastudios.com> wrote:\n>>>>\n>>>> Using Git-2.11.0 with the latest git-lfs 1.5.2 (also tested with\n>>>> 1.5.3) cloning from our locally hosted gitlab CE server via HTTPS.\n>>>>\n>>>> When cloning a repo (large, 3.3 gig in git, 10.3 in LFS)  for the\n>>>> first time the clone will finish the checkout of the git part, then\n>>>> when it starts downloading the LFS parts it will reliably finish with\n>>>> a smudge filter error.\n>>>>\n>>>> This leaves the repo in an unstable condition, you can then fetch the\n>>>> lfs part without issue, but checking out the lfs files or trying a git\n>>>> reset --hard will continue to spit out the same error. As you can see,\n>>>> the actual error is not particularly useful.\n>>>>\n>>>> fatal: workers/unity/Assets/3rdPartyAssets/FORGE3D/Sci-Fi\n>>>> Effects/Effects/Debris/Meshes/debris_junk.FBX: smudge filter lfs\n>>>> failed\n>>>> Unknown command \"\"\n>>>>\n>>>> Possibly it's due to the file extension being all capital letters, we\n>>>> did manage to change the error by recommitting the file with a\n>>>> lowercase extension, but it failed on the next file (which also had a\n>>>> capital letter extension).\n>>>>\n>>>> This has happened on multiple fresh windows 10 64 bit installs,\n>>>> different machines and target directories (to hopefully remove the\n>>>> possibility of file permissions) where cloning is taking place.\n>>>>\n>>>> The solution is to back level to Git 2.10.2 and the error disappears.\n>>>>\n>>>> More than willing to provide any further information,\n>>>\n>>> Hi Nick,\n>>>\n>>> debris_junk.FBX is not stored properly in Git LFS.\n>>> I explained the problem in detail here:\n>>> https://github.com/git-lfs/git-lfs/issues/1729\n>>>\n>>> You should add the file properly to GitLFS to fix the problem.\n>>> However, I think this is a regression in GitLFS and I hope it will\n>>> be fixed in the next version.\n>>>\n>>> No change/fix in Git is required.\n>>>\n>>> Cheers,\n>>> Lars\n>\n\nThank gmail for the top posting, hard enough getting it to send non html mail :(\n\nJust to add a bit more to the discussion, we went and had a look at\nthat directory which was freshly cloned with 2.10.2 and 1.5.3 and the\nfiles were there (400 KB + FBX files, not 2KB pointers) after the git\nreset --hard, we're actually looking at renaming all those files, as\nthat isn't the only one unfortunately..\n"}]}