On Fri, 20 Apr 2007, Junio C Hamano wrote: > "Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > > > The mess known as the progress meter in merge-recursive was my own > > fault; I put it in thinking that we might be spending a lot of time > > resolving unmerged entries in the index that were not handled by > > the simple 3-way index merge code. > > > > Turns out we don't really spend that much time there, so the progress > > meter was pretty much always jumping to "(n/n) 100%" as soon as > > the program started. That isn't a very good indication of progress. > > I would propose removing the progress meter for "Checking out > files" in unpack-trees, for the same reason. Maybe it should instead be arranged to only show the progress meter when the timer expires the first time (or, maybe, if it expires a few times). Rather than deciding whether it's going to be slow based on the total number, decide based on whether it's taken long enough for the user to wonder what's going on yet. -Daniel *This .sig left intentionally blank* - 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