That new progress meter

Hi Nico,

that new progress meter sure is amazing and useful!

Thanks,
Dscho

On Fri, Nov 02, 2007 at 06:36:35PM +0000, Johannes Schindelin wrote:

Hi Nico,

that new progress meter sure is amazing and useful!

  I do agree. There seems to be some glitches though, here is how my
output looks after a git fetch I just did on git.git:

    remote: Generating pack...
    remote: Done counting 310 objects.
    remote: Deltifying 310 objects...           | Here we have a glitch |
    remote:  100% (310/310) done                 `-------vvvv----------'
    remote: Total 310 (delta 160), reused 178 (delta 112)iB/s
    Receiving objects: 100% (310/310), 379.98 KiB | 136 KiB/s, done.
    Resolving deltas: 100% (160/160), done.
    * refs/remotes/origin/html: fast forward to branch 'html' of git://git.kernel.org/pub/scm/git/git
      old..new: 1c70883..7ae0ab2
    * refs/remotes/origin/maint: fast forward to branch 'maint' of git://git.kernel.org/pub/scm/git/git
      old..new: 136e631..f45e867
    * refs/remotes/origin/man: fast forward to branch 'man' of git://git.kernel.org/pub/scm/git/git
      old..new: 9850e2e..44dd7e0
    * refs/remotes/origin/master: fast forward to branch 'master' of git://git.kernel.org/pub/scm/git/git
      old..new: 3e4bb08..e3d6d56
    * refs/remotes/origin/next: fast forward to branch 'next' of git://git.kernel.org/pub/scm/git/git
      old..new: a93d0b0..536f64a
    * refs/remotes/origin/pu: forcing update to non-fast forward branch 'pu' of git://git.kernel.org/pub/scm/git/git
      old...new: eb57be8...bf1284a

FWIW, maybe instead using spaces to erase lines we could use minimal
vt100 codes[0] like:

Erase End of Line       <ESC>[K
    Erases from the current cursor position to the end of the current line. 
Erase Start of Line     <ESC>[1K
    Erases from the current cursor position to the start of the current line. 
Erase Line              <ESC>[2K
    Erases the entire current line.

  [0] http://www.termsys.demon.co.uk/vtansi.htm

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

On Sat, 3 Nov 2007, Pierre Habouzit wrote:

On Fri, Nov 02, 2007 at 06:36:35PM +0000, Johannes Schindelin wrote:

quoted

Hi Nico,

that new progress meter sure is amazing and useful!

  I do agree. There seems to be some glitches though, here is how my
output looks after a git fetch I just did on git.git:

    remote: Generating pack...
    remote: Done counting 310 objects.
    remote: Deltifying 310 objects...           | Here we have a glitch |
    remote:  100% (310/310) done                 `-------vvvv----------'
    remote: Total 310 (delta 160), reused 178 (delta 112)iB/s
    Receiving objects: 100% (310/310), 379.98 KiB | 136 KiB/s, done.
    Resolving deltas: 100% (160/160), done.

I know.  This is why i TRIED TO KEEP THE "Receiving objects" line as 
short as possible.

FWIW, maybe instead using spaces to erase lines we could use minimal
vt100 codes[0] like:

Erase End of Line       <ESC>[K
    Erases from the current cursor position to the end of the current line. 

I thought about that too, but this is not perfectly portable to all 
terminals according to a quick glance at /etc/termcap. Does the Windows 
console support it? Also we might prefer not to rely on termcap/terminfo 
library calls.

The other solution is to make the remote object summary line a bit 
longer, but this will be effective only when remote servers are 
upgraded.  Might that be good enough?


Nicolas

Nicolas Pitre, Sat, Nov 03, 2007 15:53:25 +0100:

The other solution is to make the remote object summary line a bit 
longer, but this will be effective only when remote servers are 
upgraded.  Might that be good enough?

How about keeping track of the length of the last lines the remote end
sent (recv_sideband in sideband.c)? So that we always know how much
spaces to add to clear up to the end of line.