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 statusOn branch masterGit 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 statusOn branch masterGit 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-files2ab9f1e447 * 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 statusOn branch masterGit 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-files2ab9f1e447 * Test.lfs$

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

9. Test:

   • git lfs status: no filenames output anymore

     $ git lfs statusOn branch masterGit 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-files2ab9f1e447 * 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.