.gitattributes diff filters are not respected when viewing diffs

[gschaffner]

Version info

• OS: Manjaro GNU/Linux 18.0.4
• Build: 1116

Description

Files with diff filters set in .gitattributes do not have their filters respected when viewing diffs in Sublime Merge. Instead, the diff says only <binary file changed>.

This behavior is observed with git-crypt in particular, but this may also apply to other filters applied in .gitattributes

Steps to reproduce

Steps to reproduce the behavior:

1. Install git-crypt and initialize it on a repository. Instructions for initialization are here.

$ mkdir test-repo && cd test-repo
$ git init
$ git crypt init
$ git crypt add-gpg-user emailforyourgpgkey@example.com

2. Configure git-crypt to act on a file.

$ echo "secretfile filter=git-crypt diff=git-crypt" > .gitattributes
$ git add . && git commit -m "Add secretfile encryption to .gitattributes"

3. Modify that file and stage the changes.

$ echo "this is secret" > secretfile && git add .

4. View the diff in Sublime Merge.

$ smerge .

Expected behavior

Instead of <binary file changed>, the proper filtered diff should appear.

The proper diff can be seen with

$ git diff --staged
diff --git a/secretfile b/secretfile
new file mode 100644
index 0000000..a2446a1
--- /dev/null
+++ b/secretfile
@@ -0,0 +1 @@
+this is secret

Screenshots

[srbs]

related: #448 & #428

[saikpr]

I am having the same issue with https://github.com/AGWA/git-crypt

[bb010g]

This would also be really nice for Git LFS tracked text files (filter=lfs diff=lfs merge=lfs), which diff like normal files given git config diff.lfs.textconv cat (git-lfs/git-lfs#440).

[daviehh]

This would also be very helpful in "the other direction", i.e. *.foo binary or *.foo -diff where files with suffix .foo are marked as binary, for files that are technically ascii, e.g. eps or mathematica notebook files

ref:
gitattributes: -diff
section "Identifying Binary Files" in this

[olopost]

Hi confirm the issue in sublime-merge 4

[anthroid]

Ran into the same issue when using *.xlsx diff=xdoc2txt in .gitattributes as documented here: git-scm: Diffing Binary Files

It works fine on the command line, and in other GUI clients (tested Fork and Git GUI). The issue is also still present whether using the bundled or system git binary in Sublime Merge.

[pSpitzner]

Ran into the same issue with nbstripout,
confirmed working in cli and other gui clients.

content of .gitattributes:

*.ipynb filter=nbstripout
*.ipynb diff=ipynb

[Dante3085]

Same issue with *.docx diff=pandoc in .gitattributes.

I only see people reporting on the existence of this issue (since 2019). Can someone with authority say anything about the progress on this issue?

[othyn]

Still appears to be an issue in build 2083 when using elasticdog/transcrypt

path/to/file  filter=crypt diff=crypt merge=crypt

Sublime Merge is the only git client I've used so far that fails to diff the files correctly. It shows the encrypted version of the file instead of the decrypted version. VSCode, git CLI, etc. all diff the file using the decrypted version.

Although given this issue has been open since 2019, very little hope of this being addressed any time soon?

[tomchiverton]

This make SM unusable for our use case, where we have compiled assets (>50) and .gitattributes set to

dist/** -diff

Because SM is the only Git client that doesn't do this correctly, you have to scroll past tens of lines of "working directory" changes (which aren't) to find actual changes e.g. in src/ to work with.

[bitmagewb]

This is still an issue in build 2096 with git-crypt.

[samholmes]

When will .gitattributes be supported? It's needed for developers who use Bun: https://bun.sh/docs/install/lockfile#how-do-i-inspect-bun-s-lockfile

[pSpitzner]

Maybe the issue has slipped through the cracks? Seems like something that should be easy to fix, and quite fundamental since there seem to be a number of circumstances where it matters?

Could someone from the Sublime HQ comment, please? Maybe @dpjohnst?
If more debug info is needed, Im happy to help out.

Thanks!