progress: fix progress meters when dealing with lots of work

The possibility of setting merge.renameLimit beyond 2^16 raises the
possibility that the values passed to progress can exceed 2^32.
Use uint64_t, because it "ought to be enough for anybody".  :-)

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Elijah Newren
2017-11-13 12:15:58 -08:00
committed by Junio C Hamano
parent b520abf1c8
commit d6861d0258
3 changed files with 21 additions and 20 deletions

View File

@ -534,7 +534,7 @@ void diffcore_rename(struct diff_options *options)
if (options->show_rename_progress) {
progress = start_delayed_progress(
_("Performing inexact rename detection"),
rename_dst_nr * rename_src_nr);
(uint64_t)rename_dst_nr * (uint64_t)rename_src_nr);
}
mx = xcalloc(st_mult(NUM_CANDIDATE_PER_DST, num_create), sizeof(*mx));
@ -571,7 +571,7 @@ void diffcore_rename(struct diff_options *options)
diff_free_filespec_blob(two);
}
dst_cnt++;
display_progress(progress, (i+1)*rename_src_nr);
display_progress(progress, (uint64_t)(i+1)*(uint64_t)rename_src_nr);
}
stop_progress(&progress);