user/sven/git.git/progress.c, branch v2.7.0-rc2

stop_progress_msg: convert sprintf to xsnprintf

2015-09-25T17:18:18Z

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: Jeff King Signed-off-by: Junio C Hamano

progress: store throughput display in a strbuf

2015-09-25T17:18:18Z

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: Jeff King Signed-off-by: Junio C Hamano

progress: treat "no terminal" as being in the foreground

2015-05-19T16:35:14Z

progress: treat "no terminal" as being in the foreground Commit 85cb890 (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: Jeff King Signed-off-by: Junio C Hamano

progress: no progress in background

2015-04-15T18:50:24Z

Disable the display of the progress if stderr is not the current foreground process. Still display the final result when done. Signed-off-by: Luke Mewburn Acked-by: Nicolas Pitre Signed-off-by: Junio C Hamano

progress: simplify performance measurement by using getnanotime()

2014-07-14T04:25:21Z

Calculating duration from a single uint64_t is simpler than from a struct timeval. Change throughput measurement from gettimeofday() to getnanotime(). Also calculate misec only if needed, and change integer division to integer multiplication + shift, which should be slightly faster. Signed-off-by: Karsten Blees Signed-off-by: Junio C Hamano

i18n: mark all progress lines for translation

2014-02-24T17:08:37Z

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

strbuf: create strbuf_humanise_bytes() to show byte sizes

2013-04-10T19:58:33Z

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 Signed-off-by: Junio C Hamano

change throughput display units with fast links

2009-10-14T08:19:29Z

Switch to MiB/s when the connection is fast enough (i.e. on a LAN). Signed-off-by: Nicolas Pitre Signed-off-by: Junio C Hamano

Nicolas Pitre has a new email address

2009-09-14T09:23:36Z

Due to problems at cam.org, my nico@cam.org email address is no longer valid. From now on, nico@fluxnic.net should be used instead. Signed-off-by: Nicolas Pitre Signed-off-by: Junio C Hamano

progress bar: round to the nearest instead of truncating down

2009-04-25T15:54:18Z

Often the throughput output is requested when the data read so far is one smaller than multiple of 1024; because 1023/1024 is ~0.999, it often shows up as 0.99 because the code currently truncates. Signed-off-by: Junio C Hamano