OK, I see 3 votes for cyan and 4-5 people participating in the thread,
so I'll make it cyan in the next revision.
On Tue, Nov 13, 2018 at 3:49 PM Jeff King wrote:
>
> On Mon, Nov 12, 2018 at 06:07:18PM +, Rafael Ascensão wrote:
>
> > On Mon, Nov 12, 2018 at 07:14:23AM -0500, Jeff King wrote:
On Mon, Nov 12, 2018 at 06:07:18PM +, Rafael Ascensão wrote:
> On Mon, Nov 12, 2018 at 07:14:23AM -0500, Jeff King wrote:
> > just adding a bunch of color variants. It would be nice if we could just
> > do this with a run-time parse_color("bold red") or whatever, but we use
> > these as
Rafael Ascensão writes:
> But I can see where personal preference starts to play a role here, as
> the logical solution isn't good enough. Which makes the case for being
> able to configure a bit stronger.
Yeah, our preference over time has always been "do not add to our
default color palette
On Mon, Nov 12, 2018 at 07:14:23AM -0500, Jeff King wrote:
> just adding a bunch of color variants. It would be nice if we could just
> do this with a run-time parse_color("bold red") or whatever, but we use
> these as static initializers.
I suggested those colors, but now, I think this needs to
On Mon, Nov 12, 2018 at 07:20:28PM +0900, Junio C Hamano wrote:
> nbelakov...@gmail.com writes:
>
> > diff --git a/color.h b/color.h
> > index 98894d6a17..857653df73 100644
> > --- a/color.h
> > +++ b/color.h
> > @@ -42,6 +42,24 @@ struct strbuf;
> > #define GIT_COLOR_FAINT_BLUE
nbelakov...@gmail.com writes:
> diff --git a/color.h b/color.h
> index 98894d6a17..857653df73 100644
> --- a/color.h
> +++ b/color.h
> @@ -42,6 +42,24 @@ struct strbuf;
> #define GIT_COLOR_FAINT_BLUE "\033[2;34m"
> #define GIT_COLOR_FAINT_MAGENTA "\033[2;35m"
> #define
From: Nickolai Belakovski
In order to more clearly display which branches are active, the output
of git branch is modified to mark branches checkout out in a linked
worktree with a "+" and color them in a faint light green (in contrast
to the current branch, which will still be denoted with a
7 matches
Mail list logo
