What does "size" refer to in git diff output?

git diff generates the output in the attached image. The file's hash has changed. What I don't quite understand is what specifically the "size" parameter indicates.

I assume this is size on disk. The output is generated from a cygwin linux installation on Windows so it is possible the line endings are what changed when examining and saving the file.

(side note: -1,3 and +1,3 indicate the first three lines in the file have been changed; might this be referring to metadata or is this file contents only?)

I don't see any reference to this parameter in the official documentation:

or these somewhat related questions:

It is a text file so I expect to see meaningful output if the contents changed. What reassurance do I have that the contents have not been altered?

Solution

Besides Adam's answer, note that the files that Git knows about read, in their entirety:

version https://git-lfs.github.com/spec/v1
oid <big ugly oid>
size <value>

where the OID and size values changed. The first line is a directive to the LFS wrappers that tells them: these aren't the files you're looking for. The second line tells the LFS wrappers which files they are looking for, and the third line tells the wrappers how big those files are.

But hold on a minute: what the <epithet> is all this about "LFS wrappers" anyway?

LFS is a system that is not Git, but that uses Git. LFS stands for Large File Storage. Git itself is blissfully unaware of the existence of LFS. When you install Git-LFS, it "wraps" Git and inserts, in a few strategic locations, filters that Git invokes when Git is attempting to check out (with git checkout, git reset, and the like) or add (with git add and the like) some file's content.

These filters secretly hide the actual file somewhere outside of Git. They send the file contents over to a separate server—the LFS server, which stores only the large or otherwise secreted-away files—and trick Git into storing, in the Git repository, these funny little "pointer files" that consist of the three lines you just saw.

Git does not know this has happened. If you use Git, instead of LFS-Git, you'll see the funny little pointer files. Only if you wrap your Git with the LFS wrappers, and invoke them—once you've wrapped your particular repository properly, Git will actually invoke them for you in most cases—will you see the files themselves.

Since you're viewing the wrappers, you are using an unwrapped Git. That's all there is to it. The unwrapped Git sees the pointer files. A wrapped Git is carefully tricked by the wrappers so that Git sees the substitute files but you see the real files. If and when you see the substitute files, that's a failure of the abstraction: you're seeing the underlying mechanism.

If you install and set up the LFS wrappers—use the link above to find them—your Git will see the wrapped files but the wrappers will sneakily substitute in the large files instead, and you should see the files that someone wants you to use. That someone, whoever that is, doesn't want you to use the wrappers: they're just for LFS.