Stefan Beller <sbeller@xxxxxxxxxx> writes: > Try it out via > ./git-format-patch --mark-moved 15ef69314d^..15ef69314d > to see if you like it. > > This separates the coloring decision from the detection of moved lines. > When giving --mark-moved, move detection is still performed and the output > markers are adjusted to */~ for new and old code. > > git-apply and git-am will also accept these patches by rewriting those > signs back to +/-. > > Signed-off-by: Stefan Beller <sbeller@xxxxxxxxxx> > --- This does not have anything to do with the range-diff topic, but would stand on its own merit. I have a mixed feeling about this. If you need to convince "GNU patch" maintainers to accept these two signs, then probably it is not worth the battle of incompatiblity. If it is truly a worthy innovation, they would follow suit, which is how they learned to take our renaming diffs without us prodding them. I just do not get the gut feeling that it would happen for this particular thing, and I am not convinced myself enough to sell this to "patch" maintainers and expect to be taken seriously. When reviewing anything complex that would be helped by moved code highlighting, I do not think a normal person would choose to review such a change only inside MUA. I certainly won't. I'd rather apply the patch and view it within a larger context than the piece of e-mail that was originally sent offers, with better tools like -W and --color-moved applied locally. So in that sense, I do not think I'd appreciate lines that begin with '~'/'*' as different kind of '-'/'+', as helpful hints; at least until my eyes get used to them, they would only appear as distraction. In other words, I have this nagging suspicion that people who suggested to you that this would help in e-mail workflow are misguided and they do not understand e-mail workflow in the first place, but perhaps it is just me. Thanks.
