Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > My only comment is that I would find the diff to `upload-pack.c` much > easier to parse if the `arg` variable hadn't been renamed. If we only look at the patch text, perhaps. What is left in the resulting file is what people will be reading in the coming years, and because instead of just one string (whose name did not matter and a short-and-sweet arg was a perfect name for it), we now have to deal with two strings (one is the full and real name, and the other is the name without namespace prefix) we need to be clear which is which, the rename is an essential part of the patch to keep the result easier to understand. When I apply a patch to my tree to review it (e-mailed patch review is merely an efficient way to transmit the change---I do not expect that I can always review all non-trivial patches without stepping out of my MUA). My review, after noticing typos, style glitches and design issues, of code and its correctness will begin after that. "git show" can be driven with different options and in some cases use of certaion options helps seeing what is going on quite well. "--diff-algorithm" shifts which preimage lines match which postimage lines and sometimes helps reduce the clutter greatly. "--word-diff" is a great tool to see where in reflowed documentation patch actual changes are. "--color-moved" lets reviewer skip pure code movement, various options to "ignore space" sometimes helps declutter the patch. etc. I wonder if we already have an option (or if there isn't, if we can design such a new option cleanly), that would help in this case. Essentially, what you want is an "I know what used to be arg is renamed to refname_nons in this patch; take advantage of that knowledge and show a diff that is less cluttered" option. Thanks for a comment, anyway.
