6

I added some binary files to a git repo on Ubuntu 14.04 linux, pushed those files to a GitHub remote then pulled them to existing clones on OS X El Capitan and Windows 10. git status on OS X and Windows shows some of these files as modified even though they have not been touched. It continues to shown them as changed even after git reset --hard and git checkout.

Note, I am using Git LFS (Large File Storage) with these files.

Here is the output from git diff on OS X where only 1 file shows as modified:

Marks-MacBook:KTX mark$ git diff other_lib/linux/Release-x64/libSDL2main.a
diff --git a/other_lib/linux/Release-x64/libSDL2main.a b/other_lib/linux/Release-x64/libSDL2main.a
index 4202f6f..2797199 100644
Binary files a/other_lib/linux/Release-x64/libSDL2main.a and b/other_lib/linux/Release-x64/libSDL2main.a differ

and

Marks-MacBook:KTX mark$ git diff --raw other_lib/linux/Release-x64/libSDL2main.a
:100644 100644 4202f6f... 0000000... M  other_lib/linux/Release-x64/libSDL2main.a

The files are marked -text in .gitattributes so there should not be any issues with EOL markers. What else could cause the different sha1 results and git diff to report the binary files differ?

I added a diff=bin to .gitattributes for *.a files where bin uses textconv = hexdump -v -C. After this git diff reports no differences but git status still shows the files as modified.

As an additional test, I copied the original .a file from linux to OS X and used diff to compare it with the copy in my git working tree. They are identical. git status on the linux repo clone reports the working tree file, that I copied, is unmodified.

Any suggestions?

The following is no longer true; the repo has been fixed as described in my answer.

You can try for yourselves. The repo & branch is on GitHub at https://github.com/KhronosGroup/KTX/tree/incoming. The file showing the problem on OS X is other_lib/linux/Release-x64/libSDL2main.a. There is no problem with any of the other .a files under other_lib/linux.

On Windows a few more files are shown as modified including some that are symbolic links on Linux. I want to concentrate on the OS X case for now since it is simpler.

msc
  • 1,549
  • 2
  • 12
  • 19

1 Answers1

5

I figured out the problem. It was with the configuration on the Linux host. Thanks to Edward Thomson for prompting me to look at the git-lfs configurations.

Running git lfs init on the Linux host, deleting & re-adding the binary files to the repo there and pushing to the remote has fixed the problem. To pull the update to the OS X and Windows hosts, I had to run git reset --hard on them to reset back to a commit without the offending files.

I had not run git lfs init, having thought that this step would be part of the scripts run by apt-get install. This meant that the files were not actually stored in LFS, because the smudge and clean filters on the Linux host were no-ops, but the .gitattributes file was causing the OS X and Windows hosts to run the LFS smudge filter on checkout.

Community
  • 1
  • 1
msc
  • 1,549
  • 2
  • 12
  • 19
  • Can you elaborate a bit on this? I have the same problem. Everything works fine in OS X (I don't even need to do `git lfs pull`, simply `git checkout` will automatically down the large files). But when I clone in Linux, `git checkout` does not automatically download the files and further, if I `git lfs pull`, I they all show up modified but not staged in `git status`. – cjbottaro Feb 11 '16 at 01:39
  • Because git lfs init had not been run on Linux, there was no Git LFS filter so when I added new large .a files, they were stored in the git repo in the standard way, i.e the entire file rather than a link. I then pushed these to a remote and pulled them to OS X. On OS X where GIT LFS filters were set up, git diff ran the LFS clean filter which, I presume, changed the file to a reference to a link to LFS storage. So the diff failed because it was comparing the full file stored in the repo with the link to LFS storage. Hope this helps. – msc May 06 '16 at 04:01