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@xxxxxxxxxx
OOO http://www.madism.org
Attachment:
pgpCsW5tBvfkG.pgp
Description: PGP signature
