Nicolas Pitre <nico@xxxxxxx> wrote:
> On Fri, 20 Apr 2007, Junio C Hamano wrote:
>
> > Originally I thought it would take too long to check out many
> > files and to prevent people from getting bored, I added progress
> > meter. But it feels a bit too noisy; let's disable it.
...
> What about looking at the number of files checked out after say 2
> seconds, and if it is still below 50% of the total then turn on the
> progress display?
I agree completely with Nico, and everyone else.
Nico's approach is the right way to handle that particular progress
meter. It should also be enabled the same way in git-checkout.sh
and git-merge.sh (for the fast-forward case).
On Windows, with a cheap+slow 5400 RPM IDE drive, a slow processor
and a virus scanner that has higher priority than the mouse driver,
a simple branch switch that updates only 500 files (out of almost
10,000) can take 30 seconds. Ok, sure, maybe I shouldn't switch
branches on such horrid hardware[*1*], but a progress meter would
be very nice for when I do.
On the other hand, the one I removed from merge-recursive was
braindamaged. It only knew the amount of work remaining once it
had finished it. That meant the meter was completely useless.
Though maybe something based on a 2 second timer like Nico is
proposing for read-tree might still be useful in merge-recursive.
*1*: Of course my Solaris 9 system does that switch so fast it makes
my head spin. Ahh, what a good system modern UNIXes are...
--
Shawn.
-
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