On 9/27/2018 11:14 AM, Ben Peart wrote:
On 9/26/2018 2:44 PM, Derrick Stolee wrote:
On 9/26/2018 1:59 PM, Junio C Hamano wrote:
Derrick Stolee <stolee@xxxxxxxxx> writes:
Perhaps removing the middle columns of data and just "<sha> <num>)
<line>" would be easier? We could also remove tabs to save space. For
example:
builtin/remote.c
5025425dfff 864) return error(_("No such remote: '%s'"), name);
commit-reach.c
b67f6b26e35 559) continue;
b67f6b26e35 569) from->objects[i].item->flags |= assign_flag;
b67f6b26e35 570) continue;
b67f6b26e35 576) result = 0;
b67f6b26e35 577) goto cleanup;
ll-merge.c
d64324cb60e 379) marker_size = DEFAULT_CONFLICT_MARKER_SIZE;
remote-curl.c
c3b9bc94b9b 181) options.filter = xstrdup(value);
This does still pad the data by a bit, but should be more readable.
Most "uncovered" code will be indented at least one level.
We do lose the author information, but keen readers could identify
code they are interested in by filename and then look up the commit
by OID later.
I personally find the author data very useful as it makes it trivial
for me to scan for and find changes I'm responsible for. Just scanning
the output of the mail and looking for file names I may have changed
lately is much more laborious - meaning I'm much less likely to
actually do it :-).
Perhaps a reasonable compromise would be to put the author name once
with the block of changes (like you are doing for the file name)
rather than on every line that changed and wasn't executed.
I've been playing with an extra footer that gives the 'git log
--oneline' output for all commits mentioned in the line-by-line summary.
While it isn't right next to the code, it would be something to look at
if you only have time to check "Are any of these lines mine?"
