[PATCH 2/4] blame: fix progress total with line ranges

[SZEDER Gábor <szeder.dev@xxxxxxxxx>]

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@xxxxxxxxx>
---
 builtin/blame.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/builtin/blame.c b/builtin/blame.c
index 5efb920dd4..7d29f5dc61 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -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;
-	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);
 
-- 
2.32.0.289.g44fbea0957