1. 22 Feb, 2016 1 commit
    • Jeff King's avatar
      use xmallocz to avoid size arithmetic · 3733e694
      Jeff King authored
      We frequently allocate strings as xmalloc(len + 1), where
      the extra 1 is for the NUL terminator. This can be done more
      simply with xmallocz, which also checks for integer
      overflow.
      
      There's no case where switching xmalloc(n+1) to xmallocz(n)
      is wrong; the result is the same length, and malloc made no
      guarantees about what was in the buffer anyway. But in some
      cases, we can stop manually placing NUL at the end of the
      allocated buffer. But that's only safe if it's clear that
      the contents will always fill the buffer.
      
      In each case where this patch does so, I manually examined
      the control flow, and I tried to err on the side of caution.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      3733e694
  2. 25 Sep, 2015 2 commits
    • Jeff King's avatar
      stop_progress_msg: convert sprintf to xsnprintf · f5691aa6
      Jeff King authored
      The usual arguments for using xsnprintf over sprintf apply,
      but this case is a little tricky. We print to a fixed-size
      buffer if we have room, and otherwise to an allocated
      buffer. So there should be no overflow here, but it is still
      good to communicate our intention, as well as to check our
      earlier math for how much space the string will need.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      f5691aa6
    • Jeff King's avatar
      progress: store throughput display in a strbuf · 3131977d
      Jeff King authored
      Coverity noticed that we strncpy() into a fixed-size buffer
      without making sure that it actually ended up
      NUL-terminated. This is unlikely to be a bug in practice,
      since throughput strings rarely hit 32 characters, but it
      would be nice to clean it up.
      
      The most obvious way to do so is to add a NUL-terminator.
      But instead, this patch switches the fixed-size buffer out
      for a strbuf. At first glance this seems much less
      efficient, until we realize that filling in the fixed-size
      buffer is done by writing into a strbuf and copying the
      result!
      
      By writing straight to the buffer, we actually end up more
      efficient:
      
        1. We avoid an extra copy of the bytes.
      
        2. Rather than malloc/free each time progress is shown, we
           can strbuf_reset and use the same buffer each time.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      3131977d
  3. 19 May, 2015 1 commit
    • Jeff King's avatar
      progress: treat "no terminal" as being in the foreground · a4fb76ce
      Jeff King authored
      progress: treat "no terminal" as being in the foreground
      
      Commit 85cb8906 (progress: no progress in background,
      2015-04-13) avoids sending progress from background
      processes by checking that the process group id of the
      current process is the same as that of the controlling
      terminal.
      
      If we don't have a terminal, however, this check never
      succeeds, and we print no progress at all (until the final
      "done" message). This can be seen when cloning a large
      repository; instead of getting progress updates for
      "counting objects", it will appear to hang then print the
      final count.
      
      We can fix this by treating an error return from tcgetpgrp()
      as a signal to show the progress.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      a4fb76ce
  4. 15 Apr, 2015 1 commit
  5. 14 Jul, 2014 1 commit
  6. 24 Feb, 2014 1 commit
  7. 10 Apr, 2013 1 commit
    • Antoine Pelisse's avatar
      strbuf: create strbuf_humanise_bytes() to show byte sizes · 079b546a
      Antoine Pelisse authored
      Humanization of downloaded size is done in the same function as text
      formatting in 'process.c'. The code cannot be reused easily elsewhere.
      
      Separate text formatting from size simplification and make the
      function public in strbuf so that it can easily be used by other
      callers.
      
      We now can use strbuf_humanise_bytes() for both downloaded size and
      download speed calculation. One of the drawbacks is that speed will
      now look like this when download is stalled: "0 bytes/s" instead of
      "0 KiB/s".
      Signed-off-by: Antoine Pelisse's avatarAntoine Pelisse <apelisse@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      079b546a
  8. 14 Oct, 2009 1 commit
  9. 14 Sep, 2009 1 commit
  10. 25 Apr, 2009 1 commit
  11. 08 Jun, 2008 1 commit
    • Boyd Lynn Gerber's avatar
      progress.c: avoid use of dynamic-sized array · d4c44443
      Boyd Lynn Gerber authored
      Dynamically sized arrays are gcc and C99 construct.  Using them hurts
      portability to older compilers, although using them is nice in this case
      it is not desirable.  This patch removes the only use of the construct
      in stop_progress_msg(); the function is about writing out a single line
      of a message, and the existing callers of this function feed messages
      of only bounded size anyway, so use of dynamic array is simply overkill.
      Signed-off-by: Boyd Lynn Gerber's avatarBoyd Lynn Gerber <gerberb@zenez.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      d4c44443
  12. 20 Nov, 2007 1 commit
    • Johannes Sixt's avatar
      Flush progress message buffer in display(). · 137a0d0e
      Johannes Sixt authored
      This will make progress display from pack-objects (invoked via
      upload-pack) more responsive on platforms with an implementation
      of stdio whose stderr is line buffered.
      
      The standard error stream is defined to be merely "not fully
      buffered"; this is different from "unbuffered".  If the
      implementation of the stdio library chooses to make it line
      buffered, progress reports that end with CR but do not contain
      LF will accumulate in the stdio buffer before written out.  A
      fflush() after each progress display gives a nice continuous
      progress.
      Signed-off-by: default avatarJohannes Sixt <johannes.sixt@telecom.at>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      137a0d0e
  13. 08 Nov, 2007 2 commits
    • Nicolas Pitre's avatar
      nicer display of thin pack completion · a984a06a
      Nicolas Pitre authored
      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: default avatarNicolas Pitre <nico@cam.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      a984a06a
    • Nicolas Pitre's avatar
      make display of total transferred fully accurate · 53ed7b5a
      Nicolas Pitre authored
      The minimum delay of 1/2 sec between successive throughput updates might
      not have been elapsed when display_throughput() is called for the last
      time, potentially making the display of total transferred bytes not
      right when progress is said to be done.
      
      Let's force an update of the throughput display as well when the
      progress is complete.  As a side effect, the total transferred will
      always be displayed even if the actual transfer rate doesn't have time
      to kickin.
      Signed-off-by: default avatarNicolas Pitre <nico@cam.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      53ed7b5a
  14. 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: default avatarNicolas Pitre <nico@cam.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      218558af
  15. 01 Nov, 2007 2 commits
    • Nicolas Pitre's avatar
      Show total transferred as part of throughput progress · 81f6654a
      Nicolas Pitre authored
      Right now it is infeasible to offer to the user a reasonable concept
      of when a clone will be complete as we aren't able to come up with
      the final pack size until after we have actually transferred the
      entire thing to the client.  However in many cases users can work
      with a rough rule-of-thumb; for example it is somewhat well known
      that git.git is about 16 MiB today and that linux-2.6.git is over
      120 MiB.
      
      We now show the total amount of data we have transferred over
      the network as part of the throughput meter, organizing it in
      "human friendly" terms like `ls -h` would do.  Users can glance at
      this, see that the total transferred size is about 3 MiB, see the
      throughput of X KiB/sec, and determine a reasonable figure of about
      when the clone will be complete, assuming they know the rough size
      of the source repository or are able to obtain it.
      
      This is also a helpful indicator that there is progress being made
      even if we stall on a very large object.  The thoughput meter may
      remain relatively constant and the percentage complete and object
      count won't be changing, but the total transferred will be increasing
      as additional data is received for this object.
      
      [from an initial proposal from Shawn O. Pearce]
      Signed-off-by: default avatarNicolas Pitre <nico@cam.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      81f6654a
    • Nicolas Pitre's avatar
      make sure throughput display gets updated even if progress doesn't move · 3e935d19
      Nicolas Pitre authored
      Currently the progress/throughput display update happens only through
      display_progress().  If the progress based on object count remains
      unchanged because a large object is being received, the latest throughput
      won't be displayed.  The display update should occur through
      display_throughput() as well.
      Signed-off-by: default avatarNicolas Pitre <nico@cam.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      3e935d19
  16. 30 Oct, 2007 3 commits
  17. 17 Oct, 2007 1 commit
  18. 23 May, 2007 1 commit
  19. 23 Apr, 2007 3 commits