Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.gitattributes diff filters are not respected when viewing diffs #568

Open
gschaffner opened this issue Aug 24, 2019 · 12 comments
Open

.gitattributes diff filters are not respected when viewing diffs #568

gschaffner opened this issue Aug 24, 2019 · 12 comments
Labels
bug Something isn't working

Comments

@gschaffner
Copy link

gschaffner commented Aug 24, 2019

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
  1. 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"
  1. Modify that file and stage the changes.
$ echo "this is secret" > secretfile && git add .
  1. 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
Copy link

srbs commented Aug 27, 2019

related: #448 & #428

@saikpr
Copy link

saikpr commented Aug 5, 2020

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

@bb010g
Copy link

bb010g commented Oct 20, 2020

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
Copy link

daviehh commented Jul 19, 2021

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

@dpjohnst dpjohnst added the bug Something isn't working label Jul 28, 2021
@olopost
Copy link

olopost commented Nov 5, 2021

Hi confirm the issue in sublime-merge 4

@anthroid
Copy link

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
Copy link

pSpitzner commented Dec 29, 2022

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
Copy link

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
Copy link

othyn commented Apr 6, 2023

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
Copy link

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
Copy link

bitmagewb commented May 13, 2024

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

@samholmes
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests