"Joachim Schmitz" <j...@schmitz-digital.de> writes:
>> From: Junio C Hamano [mailto:gits...@pobox.com]
>> Sent: Tuesday, September 04, 2012 8:47 PM
>> To: Joachim Schmitz
>> Cc: email@example.com; 'Johannes Sixt'
>> Subject: Re: [PATCH 1/2] Support for setitimer() on platforms lacking it
>> Junio C Hamano <gits...@pobox.com> writes:
>> > "Joachim Schmitz" <j...@schmitz-digital.de> 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
>> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html