Deal with clean filters somehow

[Kyuuhachi]

Is your feature request related to a problem? Please describe. If you edit a file that is covered by a filter.*.clean rule, the diff detection does not work very well. I do realize this is not really possible to handle well since filters can do literally anything, but it does make a suboptimal editing experience.

Describe the solution you'd like A non-exhaustive list of possible implementations, roughly in order of complexity:

1. Doing nothing, leave it as it currently is.
2. Show an indicator, hide the signs, etc for files affected by a clean rule. Not great, but might be better than showing a completely incorrect diff.
3. Add a command for opening a split buffer showing the result of the filter (preferably live, but some filters might only work on disk-saved files, I don't know the specifics), and diffing that result with the index. This would probably be as close to an optimal editing experience as one can reasonably get. Would probably be lots of effort for a niche feature, so perhaps this would be better off as a separate plugin.
4. Possibly augment the above with smudging the file back if applicable, but I would guess smudging is even rarer than cleaning.

Describe alternatives you've considered Discussed above.

Additional context Nothing in particular.

[lewis6991]

TIL about git smudging and cleaning.

If smudge/clean commands all work via stdin/stdout, we could simply apply the filters before diffing?

Would add quite a lot of complexity and probably slow things down, but not against doing this at some point.

[Kyuuhachi]

Yeah, they use stdin/out (not sure if they even get to know the filename they're working on). The problem (at least how I understand it) is how to display the diff in the editor; even with a simple filter such as tac, the diff lines don't really map onto editor lines.

[lewis6991]

Don't we just need to adapt the output of git show <path> and pass it through the filter which can then be compared to the working copy (the buffer contents)?

[Kyuuhachi]

I'm not really familiar withgit show; it seems to show diffs for the latest commit?

From what I've noticed, git diff diffs between the raw index file and the cleaned working copy, rather than between the smudged index file and the raw working copy. Though I agree that for realtime editing, including the raw working copy, and therefore the smudged index file, would make more sense. (Please excuse me if I'm getting the terminology wrong.)

[lewis6991]

git show :0:<path> will output the version of the file in the index (e.g. git show :0:Makefile.

From what I've noticed, git diff diffs between the raw index file and the cleaned working copy

We can do this.

Though I agree that for realtime editing, including the raw working copy, and therefore the smudged index file, would make more sense. (Please excuse me if I'm getting the terminology wrong.)

I don't really know which one makes more sense, I've never used these filters.

Both versions of the diff input are available as string variables in the plugin so we can filter either one in whatever way we want. The question is will the outputs be usable? If a filter is just changing single words in a file, then it would work. If they are removing/adding lines of text, then the signs will be wrong. Maybe if the line count changes we go with your option 2?

[lewis6991]

If you (or anyone) wants to prototype anything, the diff happens here: https://github.com/lewis6991/gitsigns.nvim/blob/06aefb1867687ee2b1d206fd5d19a2b254c62f2c/teal/gitsigns/manager.tl#L321

We just need to augment bcache.compare_text or buftext.

[Jak-Ch-ll]

I'm not really familiar withgit show; it seems to show diffs for the latest commit?

From what I've noticed, git diff diffs between the raw index file and the cleaned working copy, rather than between the smudged index file and the raw working copy. Though I agree that for realtime editing, including the raw working copy, and therefore the smudged index file, would make more sense. (Please excuse me if I'm getting the terminology wrong.)

Hi, I was just experimenting with the filter functionality in Git and came across this issue with gitsigns.nvim. I wanted to add that using the smudged index file would not work in all cases, as smudge and clean are not necessarily complementary to each other. A good example would be to have a formatter in clean and nothing for smudge. The Git documentation actually shows this in an example. Under the image they use indent for cleaning, while smudge is just cat, which does nothing.

[joaomendoncaa]

The problem still persists when using git-crypt.

Is there any news related to this issue outside of this issue. (pardon the redundancy)

[lewis6991]

Nope