"Joachim Schmitz" <jojo@xxxxxxxxxxxxxxxxxx> writes: >> From: Junio C Hamano [mailto:gitster@xxxxxxxxx] >> Sent: Tuesday, September 04, 2012 8:47 PM >> To: Joachim Schmitz >> Cc: git@xxxxxxxxxxxxxxx; 'Johannes Sixt' >> Subject: Re: [PATCH 1/2] Support for setitimer() on platforms lacking it >> >> Junio C Hamano <gitster@xxxxxxxxx> writes: >> >> > "Joachim Schmitz" <jojo@xxxxxxxxxxxxxxxxxx> writes: >> > >> >>> Only with the observation of "clone", I cannot tell if your timer is >> >>> working. You can try repacking the test repository you created by >> >>> your earlier "git clone" with "git repack -a -d -f" and see what >> >>> happens. >> >> >> >> It does update the counter too. >> > >> > Yeah, that was not a very good way to diagnose it. >> > >> > You see the progress from pack-objects (which is the underlying >> > machinery "git repack" uses) only because it knows how many objects >> > it is going to pack, and it updates the progress meter for every >> > per-cent progress it makes, without any help from the timer >> > interrupt. >> >> I think the "Counting objects: $number" phase is purely driven by >> the timer, as there is no way to say "we are done X per-cent so >> far". >> >> Doesn't your repack show "Counting objects: " with a number once, >> pause forever and then show "Counting objects: $number, done."? > > Yes, only once, when it is done > $ ./git repack -a -d -f > warning: no threads support, ignoring --threads > Counting objects: 140302, done. > Compressing objects: 1% (1385/138407) So this strongly suggests that (1) your "poor-man's" is not a real substitute for recurring itimer, and (2) users could live with the progress.c code without any itimer firing. Perhaps a no-op macro would work equally well? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html