Reputation: 51
We have a git repo that is exclusively setup to store large binary files; the intention is that every file will be stored using git-lfs (which is new to most of the team). There are 106564 files.
We are running in to issues where certain team members (graphic artists - who are not git experts) are committing changes without git-lfs installed and we're consequently running in to issues where we see this warning:
Encountered 1 file(s) that should have been pointers, but weren't:
I've written some python code to compare the output of these two commands:
git ls-files (list all files)
git lfs ls-files -n (list all files tracked by lfs)
The difference between the two lists (once I've dealt with some other issues) in theory provides me with a list of files not tracked by lfs. Before I start going further down the rabbit hole, I'd like to manually confirm on a file basis if my code is working. According to my code I have 1008 not tracked by LFS, if I run the following command on one of the 1008 files I get this output:
git check-attr -a dirA/dirB/dirC/aFile.ext
gives:
dirA/dirB/dirC/aFile.ext: diff: lfs
dirA/dirB/dirC/aFile.ext: merge: lfs
dirA/dirB/dirC/aFile.ext: filter: lfs
dirA/dirB/dirC/aFile.ext: crlf: unset
In this case the particular file shows up in the “git ls-files” list but not in the “git lfs ls-files” list, implying to me that the file is not tracked by lfs; yet the output of the “git check-attr -a” command leads me to believe otherwise… What am I missing and is there something better than the “git check-attr -a” command to check a file?
I’m using git lfs version as follows on Ubuntu 20.04:
git-lfs/3.3.0 (GitHub; linux amd64; go 1.19.3)
I was expecting the following command to tell me this file is not tracked by lfs:
git check-attr -a dirA/dirB/dirC/aFile.ext
It doesn't! Ultimately I'm looking to migrate these files to lfs.
Upvotes: 4
Views: 1615