The diff process in libgit2 automatically assumes that files over ~536MB are binary files. This causes the diff process to assign a GIT_DIFF_FLAG_BINARY to the file (see here). When the GIT_DIFF_FLAG_BINARY flag is set on a file it will eventually set that flag on the delta too causing the diff process to avoid generating hunks for the patches on the diff. Instead, it generates a binary object on any patch (I assume there is only one at this point, I have not seen otherwise).
The binary object is not exposed properly via the ConvenientPatch object in NodeGit. It should be so we can then expose the content of the binary object. Normally, this would probably not be an issue, but if we filter the binary content--say with Git LFS--we cannot see any diff output for files over the max file size threshold.
Here is where the binary object will be generated instead of hunks as any delta with the GIT_DIFF_FLAG_BINARY flag calls the binary callback instead of the diff callback and never emits the diff.
Another potential issue is deflating the filtered content on the binary object. It appears that libgit2 deflates the content regardless of what it is, so this could mean that even if we expose the binary object we won't be able to actually see the filtered content. This may not be an issue, I guess we will need to see that the final content of the binary object is after it has been exposed.
@implausible, if you could look into this that would be amazing. If not I will look into it in a couple weeks.
The diff process in libgit2 automatically assumes that files over ~536MB are binary files. This causes the diff process to assign a
GIT_DIFF_FLAG_BINARYto the file (see here). When theGIT_DIFF_FLAG_BINARYflag is set on a file it will eventually set that flag on the delta too causing the diff process to avoid generating hunks for the patches on the diff. Instead, it generates a binary object on any patch (I assume there is only one at this point, I have not seen otherwise).The binary object is not exposed properly via the
ConvenientPatchobject in NodeGit. It should be so we can then expose the content of the binary object. Normally, this would probably not be an issue, but if we filter the binary content--say with Git LFS--we cannot see any diff output for files over the max file size threshold.Here is where the binary object will be generated instead of hunks as any delta with the
GIT_DIFF_FLAG_BINARYflag calls the binary callback instead of the diff callback and never emits the diff.Another potential issue is deflating the filtered content on the binary object. It appears that libgit2 deflates the content regardless of what it is, so this could mean that even if we expose the binary object we won't be able to actually see the filtered content. This may not be an issue, I guess we will need to see that the final content of the binary object is after it has been exposed.
@implausible, if you could look into this that would be amazing. If not I will look into it in a couple weeks.