Activity

1. chrisd8088 commented on Dec 3, 2025

   

   chrisd8088

   on Dec 3, 2025

   Last edited by chrisd8088

   Member

   More actions

   Hey, I'm sorry you're having trouble.

   This issue sounds very similar to the ones reported in #6061 and #6004, and so I suspect you'll find there's a pre-existing problem with your .gitattributes files.

   Git LFS v3.6.0 includes the changes from PR #5699, and as a consequence the git lfs pull command now uses the git ls-files command rather than the git ls-tree command to locate all the Git LFS pointers in your working tree. This improves the command's performance in partial checkouts of large repositories, as we no longer have to traverse the entire Git tree regardless of what you have checked out.

   However, a subtle difference occurs if you have Git LFS pointers in your repository which don't correspond to any entries in a .gitattributes file with the filter=lfs attribute. For instance, if you've accidentally removed a .gitattributes file or just removed or changed entries in one of them at some point in your commit history, that could cause this discrepancy.

   Older versions of Git LFS, which used git ls-tree to search for Git LFS pointers during a git lfs pull command, would find them regardless of whether they had a corresponding entry in a .gitattributes file, and so that's likely why you find that Git LFS v3.4.1 works for you in this instance. Newer versions of Git LFS will only locate Git LFS pointers that (a) are in your currently checked-out working tree, if you have a partial checkout, and (b) have a file path which corresponds with a .gitattributes entry that contains the filter=lfs attribute.

   If you're able to provide the contents of your .gitattributes files and the file paths that aren't being touched by the git lfs pull command, I suspect we'll be able to identify what the exact problem is.

   A quick way to check if the filter=lfs attribute is defined for a given file path is to run a git check-attr command like the following, which should report filter: lfs for the file if everything is configured correctly:

   $ git check-attr filter -- images/other.png
   images/other.png: filter: lfs
   

   ❤️React with ❤️1Reacted by devarnikdev
2. devarnikdev commented on Dec 4, 2025

   

   devarnikdev

   on Dec 4, 2025

   Last edited by devarnikdev

   Author

   More actions

   Hi , Thanks for your reply, please find my sample .gitattribute attached and as I can see it has the filter=lfs attribute:

   *.{png,jpg,jpeg,txt,csv,apk} filter=lfs diff=lfs merge=lfs -text

   Though the output of check-attr shows me unspecified :

   git check-attr filter -- abc.apk \n abc.apk: filter: unspecified
3. chrisd8088 commented on Dec 4, 2025

   

   chrisd8088

   on Dec 4, 2025

   Member

   More actions

   Though the output of check-attr shows me unspecified

   Yup, that makes sense. That explains why the git lfs pull command isn't doing what you want when you have Git LFS v.3.7.1 installed.

   As for why the filter attribute is unspecified, there's at least one problem with your configuration, and possibly two.

   First, just note that the name of the file should be .gitattributes not .gitattribute. I suspect the file is named correctly in your repository and you simply made a small typo in your comment above, but I wanted to mention this potential issue just in case.

   Second, Git doesn't implement brace expansion like certain shells, so the format *.{foo,bar} means Git will only apply the given attributes to files with the literal file extension {foo,bar}. This is likely the key reason why your files are not recognized as Git LFS files by certain Git LFS commands.

   While some shells such as Bash implement brace expansion (also known as "alternation", which was first introduced with the C shell), Git does not support this feature in its format for .gitattributes or .gitignore files.

   The gitattributes(5) manual page explains that for .gitattributes files, "The rules by which the pattern matches paths are the same as in .gitignore files, with a few exceptions", and those rules are documented in the gitignore(5) manual page. Unfortunately, though, brace expansion is not among them.

   You'll need adjust your .gitattributes file to look something like:

   *.apk filter=lfs diff=lfs merge=lfs -text
   *.csv filter=lfs diff=lfs merge=lfs -text
   *.jpg filter=lfs diff=lfs merge=lfs -text
   *.jpeg filter=lfs diff=lfs merge=lfs -text
   *.png filter=lfs diff=lfs merge=lfs -text
   *.txt filter=lfs diff=lfs merge=lfs -text
   

   ❤️React with ❤️1Reacted by devarnikdev
4. chrisd8088

   added

   duplicate

   on Dec 4, 2025
5. devarnikdev commented on Dec 9, 2025

   

   devarnikdev

   on Dec 9, 2025

   Author

   More actions

   Thanks for your detailed answer, all issues gone after expanding brace expression.
6. devarnikdev

   closed this as completedon Dec 9, 2025