Han-Wen Nienhuys writes:
>> I think the code is OK without any assert() or BUG(), and that is
>> because the design is "we just paint the keyword at the beginning of
>> what the other side of the sideband wants us to show as a single
>> unit". If the other side sends a payload with an embedded L
On Mon, Aug 6, 2018 at 7:21 PM Junio C Hamano wrote:
> > + If set, keywords at the start of the line are highlighted. The
> > + keywords are "error", "warning", "hint" and "success", and are
> > + matched case-insensitively. Maybe set to `always`, `false` (or
> > + `never`) or `aut
On Mon, Aug 6, 2018 at 7:21 PM Junio C Hamano wrote:
>
> Han-Wen Nienhuys writes:
>
> > The Git push process itself prints lots of non-actionable messages
> > (eg. bandwidth statistics, object counters for different phases of the
> > process), which obscures actionable error messages that servers
Han-Wen Nienhuys writes:
> The Git push process itself prints lots of non-actionable messages
> (eg. bandwidth statistics, object counters for different phases of the
> process), which obscures actionable error messages that servers may
s/which obscures/which obscure/, as I think that "which" re
The colorization is controlled with the config setting "color.remote".
Supported keywords are "error", "warning", "hint" and "success". They
are highlighted if they appear at the start of the line, which is
common in error messages, eg.
ERROR: commit is missing Change-Id
The Git push process
5 matches
Mail list logo
