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:

committed by
Junio C Hamano

parent
b520abf1c8
commit
d6861d0258
@ -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);
|
||||
|
||||
|
Reference in New Issue
Block a user