Re: [PATCH 07/10] color: delay auto-color decision until point of use

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> writes:

> diff --git a/color.h b/color.h
> index a190a25..d715fd5 100644
> --- a/color.h
> +++ b/color.h
> @@ -49,6 +49,16 @@ struct strbuf;
>  #define GIT_COLOR_NIL "NIL"
>  
>  /*
> + * The first three are chosen to match common usage in the code, and what is
> + * returned from git_config_colorbool. The "auto" value can be returned from
> + * config_colorbool, and will be converted by want_color() into either 0 or 1.
> + */
> +#define GIT_COLOR_UNKNOWN -1
> +#define GIT_COLOR_ALWAYS 0
> +#define GIT_COLOR_NEVER  1
> +#define GIT_COLOR_AUTO   2

The ALWAYS/NEVER somehow go against my intuition. Let me trace one
codepath starting from git_branch_config().

    branch_use_color is set from git_config_colorbool("color.branch");
    -> given "never", git_config_colorbool() returns 0;
    branch_get_color() asks want_color(branch_use_color);
    -> want_color() returns if the given value is positive.

Because git_config_colorbool() does not use the above symbolic constants,
everything goes well, but aren't these two swapped?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]