From: Han-Wen Nienhuys <hanwen@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git <git@vger.kernel.org>
Subject: Re: [PATCH] RFC Highlight keywords in remote sideband output.
Date: Mon, 30 Jul 2018 14:24:24 +0200 [thread overview]
Message-ID: <CAFQ2z_P0_gtNw0NHBYiF=-9ZB6u9VEkq89R4qH_ZTcZ5jfxbkA@mail.gmail.com> (raw)
In-Reply-To: <xmqqva91q1an.fsf@gitster-ct.c.googlers.com>
On Thu, Jul 26, 2018 at 8:50 PM Junio C Hamano <gitster@pobox.com> wrote:
> Hold your objection a bit. I'll come back to it soon ;-)
>
> It theoretically may make more sense to color on the sender side,
> but that is true only if done at a higher layer that prepares a
> string and calls into the sideband code to send. That code must
> know what the bytes _mean_ a lot better than the code at the
> sideband layer, so we do not have to guess.
>
> Having written all the above, I think you are doing this at the
> receiving end, so this actually makes quite a lot of sense. I was
> fooled greatly by "EMIT_sideband", which in reality does NOT emit at
> all. That function is badly misnamed.
fixed.
> The function is more like "color sideband payload"; actual
> "emitting" is still done at the places the code originally "emitted"
> them to the receiving user.
>
> > Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
> > Change-Id: I090412a1288bc2caef0916447e28c2d0199da47d
>
> That's an unusual trailer we do not use in this project.
Yes, I know. I forgot to strip it from v2 again, though :-(
> > +void emit_sideband(struct strbuf *dest, const char *src, int n) {
>
> Open brace on its own line.
Done.
> > + // NOSUBMIT - maybe use transport.color property?
>
> Avoid // comment.
Done
> In our codebase in C, asterisk sticks to the variable not the type.
Done.
> > + } keywords[] = {
> > + {"hint", GIT_COLOR_YELLOW},
> > + {"warning", GIT_COLOR_BOLD_YELLOW},
> > + {"success", GIT_COLOR_BOLD_GREEN},
> > + {"error", GIT_COLOR_BOLD_RED},
> > + {},
>
> Drop the last sentinel element, and instead stop iteration over the
> array using (i < ARRAY_SIZE(keywords)).
Done.
> > + for (struct kwtable* p = keywords; p->keyword; p++) {
>
> Does anybody know if we already use the variable decl inside the
> "for (...)" construct like this? I know we discussed the idea of
> using it somewhere as a weather-balloon to see if people with exotic
> environment would mind, and I certainly do not mind making this
> patch serve as such a weather-baloon, but if that is what we are
> doing, I want the commit log message clearly marked as such, so that
> we can later "git log --grep=C99" to see how long ago such an
> experiment started.
I elided this. (I had expected for the compile to enforce restrictions
like these using --std=c99.)
> > * Receive multiplexed output stream over git native protocol.
> > @@ -48,8 +95,10 @@ int recv_sideband(const char *me, int in_stream, int out)
> > len--;
> > switch (band) {
> > case 3:
> > - strbuf_addf(&outbuf, "%s%s%s", outbuf.len ? "\n" : "",
> > - DISPLAY_PREFIX, buf + 1);
> > + strbuf_addf(&outbuf, "%s%s", outbuf.len ? "\n" : "",
> > + DISPLAY_PREFIX);
> > + emit_sideband(&outbuf, buf+1, len);
> > +
>
> Let's not lose SP around "+" on both sides.
>
> Also you seem to be indenting some lines with all SP and some with
> mixture of HT and SP. We prefer to use as many 8-column HT and then
> fill the remainder with SP if needed to align with the opening
> parenthesis on line above it (imitate the way strbuf_addf() is split
> into two lines in the original in this hunk).
Fixed these, I think.
> Thanks. While there are need for mostly minor fix-ups, the logic
> seems quite sane. I think we can start without configuration and
> then "fix" it later.
I need the configuration to be able to test this, though.
> While I am OK with calling that variable "transport.<something>", we
> should not define/explain it as "color output coming from the other
> end over the wire transport". Those who want to see messages
> emitted remotely during "git fetch" in color would want to see the
> messages generated by "git fetch" locally painted in the same color
> scheme, so it makes sense to let "git fetch" pay attention and honor
> that variable even for its own locally generated messages. The
> variable instead means "color any message, either generated locally
> or remotely, during an operation that has something to do with
> object transport", or something like that.
I used color.remote for the property, but I'm happy to colorize the
bikeshed with another color.
--
Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
prev parent reply other threads:[~2018-07-30 12:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-26 17:17 [PATCH] RFC Highlight keywords in remote sideband output Han-Wen Nienhuys
2018-07-26 17:53 ` Stefan Beller
2018-07-26 18:50 ` Junio C Hamano
2018-07-30 12:24 ` Han-Wen Nienhuys [this message]
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFQ2z_P0_gtNw0NHBYiF=-9ZB6u9VEkq89R4qH_ZTcZ5jfxbkA@mail.gmail.com' \
--to=hanwen@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).