On Sat, Aug 4, 2018 at 10:15 AM Junio C Hamano <gits...@pobox.com> wrote: > > Stefan Beller <sbel...@google.com> 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 <sbel...@google.com> > > --- > > This does not have anything to do with the range-diff topic, but > would stand on its own merit.
Yes. I should have emphasized this more in the cover letter. This is more a "while at it" thing, that is easy to do due to the refactoring in previous patches. > I have a mixed feeling about this. Me, too. > 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. ok. > 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. My use case would be patches that are *not* complex, but still shuffling lots of code around, e.g. reordering functions/paragraphs in a file. > 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. There are no other people that suggested this. It was really just a quick shot "while at it" as we had the refactoring in place that enables this, and I think for trivial patches (non-complex, but lots of changes) it *may* be beneficial. But it is more for corner cases, I guess. Stefan