From: Junio C Hamano <gitster@pobox•com>
To: Eric Wong <normalperson@yhbt•net>
Cc: Jeff King <peff@peff•net>, git@vger•kernel.org
Subject: Re: [PATCH] pass transport verbosity down to git_connect
Date: Thu, 28 Jan 2016 19:19:30 -0800 [thread overview]
Message-ID: <xmqqpowljcn1.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20160129003816.GA26200@dcvr.yhbt.net> (Eric Wong's message of "Fri, 29 Jan 2016 00:38:16 +0000")
Eric Wong <normalperson@yhbt•net> writes:
> On the other hand, I'm not sure if there's anything parsing the stderr
> out of "git fetch -v" right now.
It would also affect end-user experience, depending on what new
pieces of lines are emitted to the terminal. From "git fetch -v", I
expect to see the transfer progress and the final listing of fetched
and updated refs, and as long as the line "remote: Compressing
objects" and the lines that follow do not get garbled, I would
imagine it would be fine.
...
remote: Compressing objects: 100% (1195/1195), done.
remote: Total 1869 (delta 1551), reused 841 (delta 672)
Receiving objects: 100% (1869/1869), 462.80 KiB | 0 bytes/s, done.
Resolving deltas: 100% (1551/1551), completed with 335 local objects.
From $over_there
* branch pu -> FETCH_HEAD
> In that case, perhaps only changing
> "-vv" (and documenting it) is a better idea.
I just reviewed the output that are protected by CONNECT_VERBOSE;
they look somewhere between pure debugging aid (like the protocol
dump that are shown by "fetch -vv") and progress display, and at
least to me they are much closer to the latter than the former, in
the sense that they are not _so_ annoying as the protocol dump that
are clearly not meant for the end users, and that they say "I am
looking up this host's address", "Now connecting to this host:port",
etc.
So, I personally find this addtional output not _too_ bad if we give
it with "fetch -v" (not limiting to "fetch -vv").
I dunno.
next prev parent reply other threads:[~2016-01-29 3:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-28 22:51 [PATCH] pass transport verbosity down to git_connect Eric Wong
2016-01-28 23:45 ` Junio C Hamano
2016-01-30 8:50 ` [PATCH v2] " Eric Wong
2016-01-30 13:13 ` [PATCH 2/1] support -4 and -6 switches for remote operations Eric Wong
2016-01-30 13:28 ` Eric Wong
2016-01-30 23:34 ` Torsten Bögershausen
2016-01-31 0:01 ` Eric Wong
2016-01-31 1:13 ` Jeff King
2016-02-03 4:09 ` [PATCH v2 " Eric Wong
2016-02-12 11:31 ` Eric Wong
2016-02-12 15:43 ` Torsten Bögershausen
2016-01-31 16:03 ` [PATCH " Torsten Bögershausen
2016-01-28 23:53 ` [PATCH] pass transport verbosity down to git_connect Jeff King
2016-01-29 0:38 ` Eric Wong
2016-01-29 3:19 ` Junio C Hamano [this message]
2016-01-29 3:47 ` Jeff King
2016-01-29 17:34 ` Junio C Hamano
2016-01-29 17:41 ` Jeff King
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=xmqqpowljcn1.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=normalperson@yhbt$(echo .)net \
--cc=peff@peff$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox