2017-10-15 22:06 GMT+02:00 Jeff King <peff@xxxxxxxx>: > Git's diff generation will never do such escaping by default, because it > means creating a patch that cannot be applied to get back the original > content. Indeed this would be a problem. That's where my knowledge of git's source code ends, but in that case, can't the output be discriminated against the command that was executed? Command that outputs an applicable patch -> don't escape Command that outputs a diff to see changes -> escape > There _are_ already options to create diffs that cannot be applied, like > --textconv. So it would be possible to add a similar option for > escaping. But I don't think we really need or want a separate option, > when you can already do one of: > > 1. If your files have special binary characters that are hard to see, > you can use the existing textconv system to do whatever escaping > you like. And then the Git will diff the result of the escaping, > which means you get readable diffs when they change. > > 2. Put the raw output of git's diff through a filter that escapes. We > already do this most of the time by piping through less. The most > noticeable exception is "add --patch". There you can set up a > program to filter as well. There's more information in a recent > thread here: > > https://public-inbox.org/git/20171012184736.rglkbyryauwuvn2a@xxxxxxxxxxxxxxxxxxxxx/ > > It doesn't seem out of the question to me to have an out-of-the-box > default for interactive.diffFilter which does some basic escaping (we > could even implement it inside the perl script for efficiency). Yes I read this thread, but I was left unsatisfied because I would like something out-of-the-box. Your suggestion might be the best solution then: implement some default escaping for interactive.diffFilter. Joris
