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.
Indexing. For every tracked file, Git records information such as its size, creation time and last modification time in a file known as the index. To determine whether a file has changed, Git compares its current stats with those cached in the index. If they match, then Git can skip reading the file again.
How Does Git LFS Work? Git LFS uses pointers instead of the actual files or binary large objects (blobs). So, instead of writing large files/blobs to a Git repository, you write a pointer file, and the files/blobs themselves are written to a separate server.
Recent versions of git require either "-f" (force) or "-n" (dry-run) to be specified. I use this so often, that I have an alias for this (added to your . gitconfig ) to check for files that would be deleted when you run git clean .
The git status command displays the state of the working directory and the staging area. It lets you see which changes have been staged, which haven't, and which files aren't being tracked by Git. Status output does not show you any information regarding the committed project history.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With