Re: [PATCH 3/4] progress: Fix progress meters when dealing with lots of work

2017-11-13 Thread Junio C Hamano
Elijah Newren writes: > 2) Instead of counting pairs of source/dest files compared, just > count number of dest paths completed. (Thus, we wouldn't need a value > big enough to hold rename_dst_nr * rename_src_nr, just big enough to > hold rename_dst_nr). This sounds like

Re: [PATCH 3/4] progress: Fix progress meters when dealing with lots of work

2017-11-13 Thread Elijah Newren
Thanks for the reviews and suggestions! On Sun, Nov 12, 2017 at 9:24 PM, Junio C Hamano <gits...@pobox.com> wrote: > Elijah Newren <new...@gmail.com> writes: > >> Subject: Re: [PATCH 3/4] progress: Fix progress meters when dealing with >> lots of work > &g

Re: [PATCH 3/4] progress: Fix progress meters when dealing with lots of work

2017-11-12 Thread Junio C Hamano
Elijah Newren <new...@gmail.com> writes: > Subject: Re: [PATCH 3/4] progress: Fix progress meters when dealing with lots > of work Style: s/Fix/fix/; > The possibility of setting merge.renameLimit beyond 2^16 raises the > possibility that the values passed to progress can ex

[PATCH 3/4] progress: Fix progress meters when dealing with lots of work

2017-11-10 Thread Elijah Newren
The possibility of setting merge.renameLimit beyond 2^16 raises the possibility that the values passed to progress can exceed 2^32. For my usecase of interest, I only needed to pass a value a little over 2^31. If I were only interested in fixing my usecase, I could have simply changed last_value