Stephen Kent <smk...@smkent.net> writes:

> Subject: Re: [PATCH] Add color slots for branch names in "git status --short 
> --branch"

We spell one-liner title of our commits as "<area>: <summary>"
typically.  In this case, this is about the output from the status
command, so

        status: make the color used "--shrot --branch" output configurable

or something, perhaps?

> Signed-off-by: Stephen Kent <smk...@smkent.net>
> ---
>  Documentation/config.txt               | 5 ++++-
>  builtin/commit.c                       | 4 ++++
>  contrib/completion/git-completion.bash | 2 ++
>  3 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 475e874..96e9cf8 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1137,7 +1137,10 @@ color.status.<slot>::
>       `untracked` (files which are not tracked by Git),
>       `branch` (the current branch),
>       `nobranch` (the color the 'no branch' warning is shown in, defaulting
> -     to red), or
> +     to red),
> +     `localBranch` or `remoteBranch` (the local and remote branch names,
> +     respectively, when branch and tracking information is displayed in the
> +     status short-format), or
>       `unmerged` (files which have unmerged changes).

OK.

>  color.ui::
> diff --git a/builtin/commit.c b/builtin/commit.c
> index 4e288bc..43846d5 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -1263,6 +1263,10 @@ static int parse_status_slot(const char *slot)
>               return WT_STATUS_NOBRANCH;
>       if (!strcasecmp(slot, "unmerged"))
>               return WT_STATUS_UNMERGED;
> +     if (!strcasecmp(slot, "localBranch"))
> +             return WT_STATUS_LOCAL_BRANCH;
> +     if (!strcasecmp(slot, "remoteBranch"))
> +             return WT_STATUS_REMOTE_BRANCH;
>       return -1;
>  }

OK.

I know we do not test color.status.<slot> at all (other than t4026
that makes sure a configuration from future version of Git that
specifies a slot that is not yet known to our version of Git is
safely ignored without triggering an error), but perhaps we would
want a new test or two at the end of t7508?

Thanks.

Reply via email to