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

[Junio C Hamano <gitster@pobox.com>]

Stephen Kent <smkent@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 <smkent@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.