How can I tell if a file will be uploaded to git lfs correctly?

TL;DR

If everything is set up correctly, you can verify that git LFS is going to work properly by:

1. git add the file(s) in question.
2. Do one of the following:
   • Run git lfs status and ensure the file(s) in question appear under Git LFS objects to be committed, and that they have the LFS value in parenthesis; or
   • Run git lfs ls-files and ensure the file(s) in question appear in this output.

⚠️ Important: After running git lfs track, you must run git add to refresh the state of files before calling git lfs status or git lfs ls-files. Otherwise you’ll see irrelevant output from those commands.

Also, for the record, looks like git lfs track "MyProject/Frameworks/**" is the correct one for recursive matching.

Set up and testing methodology:

1. git lfs track "*.lfs". This generates .gitattributes. Leave it unstaged.
2. Create a file in the root directory, Test.lfs. Leave it unstaged.

3. Test:

   • git lfs status: no filenames output

     $ git lfs status
     On branch master
     Git LFS objects to be pushed to origin/master:
     
     
     Git LFS objects to be committed:
     
     
     Git LFS objects not staged for commit:
     
     
     $
     

   • git lfs ls-files: no output

     $ git lfs ls-files
     $
     

4. Add git add Test.lfs.

5. Test:

   • git lfs status: Test.lfs will now be listed with an LFS suffix.

     $ git lfs status
     On branch master
     Git LFS objects to be pushed to origin/master:
     
     
     Git LFS objects to be committed:
     
             Test.lfs (LFS: 2ab9f1e)
     
     Git LFS objects not staged for commit:
     
     
     $
     

   • git lfs ls-files: Test.lfs will now be listed.

     $ git lfs ls-files
     2ab9f1e447 * Test.lfs
     $
     

6. Commit changes.

7. Test:

   • git lfs status: Test.lfs will move to the “to be pushed” section. It will have a suffix such with a bunch of numbers/letters.

     $ git lfs status
     On branch master
     Git LFS objects to be pushed to origin/master:
     
             Test.lfs (2ab9f1e44720efb7a26553e06b667a270320efb3e906553b3f9e0702538a2b3f)
     
     Git LFS objects to be committed:
     
     
     Git LFS objects not staged for commit:
     
     
     $
     

   • git lfs ls-files: Test.lfs will continue to be listed.

     $ git lfs ls-files
     2ab9f1e447 * Test.lfs
     $
     

8. Push changes. Including adding/committing/pushing .gitattributes.

9. Test:

   • git lfs status: no filenames output anymore

     $ git lfs status
     On branch master
     Git LFS objects to be pushed to origin/master:
     
     
     Git LFS objects to be committed:
     
     
     Git LFS objects not staged for commit:
     
     
     $
     

   • git lfs ls-files: Continues to output the tracked file

     $ git lfs ls-files
     2ab9f1e447 * Test.lfs
     $
     

Conclusions:

• The Git LFS objects not staged for commit section seems misleading as it never displayed any files, even those that should have been tracked by LFS.
• If you attempt to do the previous experiment with a non git-lfs tracked file, you’ll also notice that it appears under the Git LFS objects to be committed incorrectly. It is not a Git LFS object. The way you can tell that it’s not actually a Git LFS object though is to look at how it ends. If it ends with (Git: 111111111) it won’t be committed to LFS.
• To avoid the above confusions, you may want to favor git lfs ls-files over git lfs status to determine if something is going to be part of git-lfs or not.
• Another gotcha: Some applications such as Xcode will git add files in a weird way causing what should have been clear matches to not be considered for Git LFS. The solution is to unstage the files and then re-stage them.