All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre Habouzit <madcoder@debian.org>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: Carl Worth <cworth@cworth.org>, git@vger.kernel.org
Subject: Re: A tour of git: the basics (and notes on some unfriendly messages)
Date: Sat, 29 Sep 2007 11:01:21 +0200	[thread overview]
Message-ID: <20070929090121.GA4216@artemis.corp> (raw)
In-Reply-To: <20070929000056.GZ3099@spearce.org>

[-- Attachment #1: Type: text/plain, Size: 2015 bytes --]

On Sat, Sep 29, 2007 at 12:00:56AM +0000, Shawn O. Pearce wrote:
> The C based git-fetch made the http protocol almost totally silent.
> (No more got/walk messages.)  But that's actually also bad as it
> now doesn't even let you know its transferring anything at all.
> 
> There are serious issues here about getting the user the progress
> they really want.  The last item ("When will this be done?") is
> actually not possible to determine under either the native git
> protocol or HTTP/FTP.  We have no idea up front how much data must
> be transferred.  In the native git case we do know how many objects,
> but we don't know how many bytes that will be.  It could be under
> a kilobyte in one project.  That same object count for a different
> set of objects fetch could be 500M.  Radically different transfer
> times would be required.

  I'm not sure you need the ETA thing. I've used bzr only a couple of
time, I don't think it shows any kind of ETA, but I think I remember sth
like:

Stage 3/4
[==========================>                                    ] [43%]

  And that's all is needed. It's sober, and informative enough I think.


  Many git commands output are still messy and indeed, having them in C
should help in that regard. The usual culprit are I think:

  * git fetch/clone/pull/.. ;
  * git push ;
  * git repack/gc/... ;
  * git merge (even with the merge.verbosity set to the minimum it's
    still not very readable and confusing).


  I do believe that the quite verbose output git commands sometimes have
is quite confusing, and let the user think it's messy. I believe that
porcelains should be more silent, it's OK for the plumbing to spit
progress messages and so on, because people using the plumbing are able
to understand those, but porcelains should not.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2007-09-29  9:01 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-28 23:07 A tour of git: the basics (and notes on some unfriendly messages) Carl Worth
2007-09-29  0:00 ` Shawn O. Pearce
2007-09-29  0:49   ` Johannes Schindelin
2007-09-29  7:44     ` Steffen Prohaska
2007-09-29 15:06       ` Johannes Schindelin
2007-09-29 16:06         ` Steffen Prohaska
2007-09-29 16:05           ` [PATCH] WinGit: included /bin/start in the installer Steffen Prohaska
2007-09-29 16:05             ` [PATCH] WinGit: include html pages from official git.git's html branch Steffen Prohaska
2007-09-29 20:50               ` Johannes Schindelin
2007-09-29 22:13                 ` Junio C Hamano
2007-09-29 23:23                   ` Johannes Schindelin
2007-09-30  8:19                     ` Steffen Prohaska
2007-09-29  9:01   ` Pierre Habouzit [this message]
2007-09-29 10:45     ` [RFC] patch series to sketch a less verbose and frightening output Pierre Habouzit
2007-09-29 10:49       ` Pierre Habouzit
     [not found]       ` <1191062758-30631-2-git-send-email-madcoder@debian.org>
2007-09-29 14:33         ` [PATCH 1/4] Rework progress module so that it uses less screen lines, with progress bars Nicolas Pitre
2007-09-29 16:07           ` Pierre Habouzit
2007-09-30 12:45     ` A tour of git: the basics (and notes on some unfriendly messages) Wincent Colaiuta
2007-09-30 13:49       ` Pierre Habouzit
2007-09-30 14:31         ` Wincent Colaiuta
2007-09-29 21:48   ` Steffen Prohaska
2007-09-29 22:25     ` Junio C Hamano
2007-09-30  8:15       ` Steffen Prohaska
2007-09-30 10:17         ` Junio C Hamano
2007-09-30 12:44         ` Johannes Schindelin
2007-09-30 13:41           ` Steffen Prohaska
2007-09-29  0:45 ` Junio C Hamano
2007-09-30  3:38   ` Carl Worth
2007-09-30  3:38   ` Carl Worth
2007-09-29  5:32 ` Nguyen Thai Ngoc Duy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070929090121.GA4216@artemis.corp \
    --to=madcoder@debian.org \
    --cc=cworth@cworth.org \
    --cc=git@vger.kernel.org \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.