@@ -1121,9 +1121,11 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
}
sort_and_merge_range_set(&ranges);
+ lno = 0;
for (range_i = ranges.nr; range_i > 0; --range_i) {
const struct range *r = &ranges.ranges[range_i - 1];
ent = blame_entry_prepend(ent, r->start, r->end, o);
+ lno += r->end - r->start;
}
o->suspects = ent;
@@ -1152,7 +1154,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
sb.found_guilty_entry = &found_guilty_entry;
sb.found_guilty_entry_data = π
- pi.progress = start_delayed_progress_if_tty(_("Blaming lines"), sb.num_lines, show_progress);
+ pi.progress = start_delayed_progress_if_tty(_("Blaming lines"), lno, show_progress);
assign_blame(&sb, opt);
When not blaming a whole file but only a subset of its lines using the '-L<start>,<end>' option, then the "Blaming lines" progress counter can be way off, because the counter only counts the actually processed lines in the line range(s) while the expected total wrongly shows the number of lines in the given file: $ wc -l git.c 932 git.c $ GIT_PROGRESS_DELAY=0 git blame -L10,20 git.c Blaming lines: 1% (11/932), done. <...> Let's sum up the number of lines in all (sorted and merged) line ranges and specify the resulting number as expected total. (Note: when blaming the whole file, then we (implicitly) have one line range encompassing all its lines, so this approach works even when no line range was given as option.) Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> --- builtin/blame.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)