On Mon, Jun 5, 2017 at 11:23 AM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: >> * sb/diff-color-move (2017-06-01) 17 commits >> - diff.c: color moved lines differently >> - diff: buffer all output if asked to >> - diff.c: emit_line includes whitespace highlighting >> - diff.c: convert diff_summary to use emit_line_* >> - diff.c: convert diff_flush to use emit_line_* >> - diff.c: convert word diffing to use emit_line_* >> - diff.c: convert show_stats to use emit_line_* >> - diff.c: convert emit_binary_diff_body to use emit_line_* >> - submodule.c: convert show_submodule_summary to use emit_line_fmt >> - diff.c: convert emit_rewrite_lines to use emit_line_* >> - diff.c: convert emit_rewrite_diff to use emit_line_* >> - diff.c: convert builtin_diff to use emit_line_* >> - diff.c: convert fn_out_consume to use emit_line >> - diff: introduce more flexible emit function >> - diff.c: factor out diff_flush_patch_all_file_pairs >> - diff: move line ending check into emit_hunk_header >> - diff: readability fix >> >> "git diff" has been taught to optionally paint new lines that are >> the same as deleted lines elsewhere differently from genuinely new >> lines. >> >> Are we happy with these changes? > > I advertised this series e.g. for reviewing Brandons > repo object refactoring series and used it myself to inspect > some patches there[1]. I am certainly happy (but biased) with > what we have available there. > > Jacob intended to use this series > for review as well, but has given no opinion yet. I haven't had any problems thus far. Been using it for the past few days at $DAYJOB. Haven't said anything yet because I haven't really had anything to add. I like it. Thanks, Jake > > You seemed to have used it for js/blame-lib? > > -- > Those patches had a wide reviewer audience cc'd, > so I would think people are aware of this series. > > -- > Things to come, but not in this series as they are more advanced: > > Discuss if a block/line needs a minimum requirement. > > When doing reviews with this series, a couple of lines such > as "\t\t}" were marked as a moved, which is not wrong as they > really occurred in the text with opposing sign. > But it was annoying as it drew my attention to just closing > braces, which IMO is not the point of code review. > > To solve this issue I had the idea of a "minimum requirement", e.g. > * at least 3 consecutive lines or > * at least one line with at least 3 non-ws characters or > * compute the entropy of a given moved block and if it is too low, do > not mark it up. > > I am not sure if such a "minimum requirement" is the right approach > at all. The nature of this discussion comes close to the diff heuristics > at which Michael did present a wonderful solution, hence I had him cc'd > on the series as he may have some good insights on how to improve > the diffs. :) > > -- > In conclusion: > > We are happy to move to next as it seems technically sound. > > But we want more exposure on usage to point out UX bugs. > (e.g. is the default mode for just giving --color-moved good for the > majority of people/use cases? Are there subtle annoyances such > as the closing braces?) > > So maybe merge to next with the strong option to evict it > when finding more fundamentally wrong things? > > Thanks, > Stefan > > [1] > https://public-inbox.org/git/CAGZ79kZJF9iDsVgyi-hSKb6N8w0uhVCU4W-r89F0eRJPXe_4Og@xxxxxxxxxxxxxx/