1. 05 Apr, 2019 1 commit
    • Gábor Szeder's avatar
      progress: make display_progress() return void · 9219d127
      Gábor Szeder authored
      Ever since the progress infrastructure was introduced in 96a02f8f
      (common progress display support, 2007-04-18), display_progress() has
      returned an int, telling callers whether it updated the progress bar
      or not.  However, this is:
        - useless, because over the last dozen years there has never been a
          single caller that cared about that return value.
        - not quite true, because it doesn't print a progress bar when
          running in the background, yet it returns 1; see 85cb8906
          (progress: no progress in background, 2015-04-13).
      The related display_throughput() function returned void already upon
      its introduction in cf84d51c (add throughput to progress display,
      Let's make display_progress() return void, too.  While doing so
      several return statements in display() become unnecessary, remove
      Signed-off-by: Gábor Szeder's avatarSZEDER Gábor <szeder.dev@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  2. 22 Mar, 2019 1 commit
    • Jeff Hostetler's avatar
      progress: add sparse mode to force 100% complete message · 9d81ecb5
      Jeff Hostetler authored
      Add new start_sparse_progress() and start_delayed_sparse_progress()
      constructors and "sparse" flag to struct progress.
      Teach stop_progress() to force a 100% complete progress message before
      printing the final "done" message when "sparse" is set.
      Calling display_progress() for every item in a large set can
      be expensive.  If callers try to filter this for performance
      reasons, such as emitting every k-th item, progress would
      not reach 100% unless they made a final call to display_progress()
      with the item count before calling stop_progress().
      Now this is automatic when "sparse" is set.
      Signed-off-by: 's avatarJeff Hostetler <jeffhost@microsoft.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  3. 15 Nov, 2017 1 commit
  4. 19 Aug, 2017 1 commit
    • Junio C Hamano's avatar
      progress: simplify "delayed" progress API · 8aade107
      Junio C Hamano authored
      We used to expose the full power of the delayed progress API to the
      callers, so that they can specify, not just the message to show and
      expected total amount of work that is used to compute the percentage
      of work performed so far, the percent-threshold parameter P and the
      delay-seconds parameter N.  The progress meter starts to show at N
      seconds into the operation only if we have not yet completed P per-cent
      of the total work.
      Most callers used either (0%, 2s) or (50%, 1s) as (P, N), but there
      are oddballs that chose more random-looking values like 95%.
      For a smoother workload, (50%, 1s) would allow us to start showing
      the progress meter earlier than (0%, 2s), while keeping the chance
      of not showing progress meter for long running operation the same as
      the latter.  For a task that would take 2s or more to complete, it
      is likely that less than half of it would complete within the first
      second, if the workload is smooth.  But for a spiky workload whose
      earlier part is easier, such a setting is likely to fail to show the
      progress meter entirely and (0%, 2s) is more appropriate.
      But that is merely a theory.  Realistically, it is of dubious value
      to ask each codepath to carefully consider smoothness of their
      workload and specify their own setting by passing two extra
      parameters.  Let's simplify the API by dropping both parameters and
      have everybody use (0%, 2s).
      Oh, by the way, the percent-threshold parameter and the structure
      member were consistently misspelled, which also is now fixed ;-)
      Helped-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  5. 08 Nov, 2007 1 commit
  6. 05 Nov, 2007 1 commit
    • Nicolas Pitre's avatar
      make display of total transferred more accurate · 218558af
      Nicolas Pitre authored
      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: 's avatarNicolas Pitre <nico@cam.org>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  7. 30 Oct, 2007 2 commits
  8. 17 Oct, 2007 1 commit
  9. 23 May, 2007 1 commit
  10. 29 Apr, 2007 1 commit
  11. 23 Apr, 2007 3 commits