summaryrefslogtreecommitdiff
path: root/progress.h
Commit message (Collapse)AuthorAgeFilesLines
* nicer display of thin pack completionNicolas Pitre2007-11-081-0/+1
| | | | | | | | | | | In the same spirit of prettifying Git's output display for mere mortals, here's a simple extension to the progress API allowing for a final message to be provided when terminating a progress line, and use it for the display of the number of objects needed to complete a thin pack, saving yet one more line of screen display. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* make display of total transferred more accurateNicolas Pitre2007-11-051-1/+1
| | | | | | | | | | | | | | | The throughput display needs a delay period before accounting and displaying anything. Yet it might be called after some amount of data has already been transferred. The display of total data is therefore accounted late and therefore smaller than the reality. Let's call display_throughput() with an absolute amount of transferred data instead of a relative number, and let the throughput code find the relative amount of data by itself as needed. This way the displayed total is always exact. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* add throughput to progress displayNicolas Pitre2007-10-301-0/+1
| | | | | | | | | | | This adds the ability for the progress code to also display transfer throughput when that makes sense. The math was inspired by commit c548cf4ee0737a321ffe94f6a97c65baf87281be from Linus. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* make struct progress an opaque typeNicolas Pitre2007-10-301-13/+5
| | | | | | | | | This allows for better management of progress "object" existence, as well as making the progress display implementation more independent from its callers. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* more compact progress displayNicolas Pitre2007-10-171-6/+4
| | | | | | | | | | | Each progress can be on a single line instead of two. [sp: Changed "Checking files out" to "Checking out files" at Johannes Sixt's suggestion as it better explains the action that is taking place] Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* Fix the progress code to output LF only when it is really neededAlex Riesen2007-05-231-0/+1
| | | | | Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Make macros to prevent double-inclusion in headers consistent.Junio C Hamano2007-04-291-2/+2
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* provide a facility for "delayed" progress reportingNicolas Pitre2007-04-221-0/+6
| | | | | | | | This allows for progress to be displayed only if the progress has not reached a specified percentage treshold within a given delay in seconds. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* make progress "title" part of the common progress interfaceNicolas Pitre2007-04-221-2/+3
| | | | | | | If the progress bar ends up in a box, better provide a title for it too. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* common progress display supportNicolas Pitre2007-04-221-0/+14
Instead of having this code duplicated in multiple places, let's have a common interface for progress display. If someday someone wishes to display a cheezy progress bar instead then only one file will have to be changed. Note: I left merge-recursive.c out since it has a strange notion of progress as it apparently increase the expected total number as it goes. Someone with more intimate knowledge of what that is supposed to mean might look at converting it to the common progress interface. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
View Lorry Controller Status