Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Jan 20, 2015
  1. @peff @gitster

    parse_color: fix return value for numeric color values 0-8

    peff authored gitster committed
    When commit 695d95d refactored the color parsing, it missed
    a "return 0" when parsing literal numbers 0-8 (which
    represent basic ANSI colors), leading us to report these
    colors as an error.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Commits on Dec 9, 2014
  1. @peff @gitster

    parse_color: drop COLOR_BACKGROUND macro

    peff authored gitster committed
    Commit 695d95d (parse_color: refactor color storage,
    2014-11-20) introduced two macros, COLOR_FOREGROUND and
    COLOR_BACKGROUND. The latter conflicts with a system macro
    defined on Windows, breaking compilation there.
    The simplest solution is to just get rid of these macros
    entirely. They are constants that are only used in one place
    (since the whole point of 695d95d was to avoid repeating
    ourselves). Their main function is to make the magic
    character constants more readable, but we can do the same
    thing with a comment.
    Reported-by: Johannes Sixt <>
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Commits on Nov 20, 2014
  1. @peff @gitster

    parse_color: recognize "no$foo" to clear the $foo attribute

    peff authored gitster committed
    You can turn on ANSI text attributes like "reverse" by
    putting "reverse" in your color spec. However, you cannot
    ask to turn reverse off.
    For common cases, this does not matter. You would turn on
    "reverse" at the start of a colored section, and then clear
    all attributes with a "reset". However, you may wish to turn
    on some attributes, then selectively disable others. For
      git log --format="%C(bold ul yellow)%h%C(noul) %s"
    underlines just the hash, but without the need to re-specify
    the rest of the attributes. This can also help third-party
    programs, like contrib/diff-highlight, that want to turn
    some attribute on/off without disrupting existing coloring.
    Note that some attribute specifications are probably
    nonsensical (e.g., "bold nobold"). We do not bother to flag
    such constructs, and instead let the terminal sort it out.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
  2. @peff @gitster

    parse_color: support 24-bit RGB values

    peff authored gitster committed
    Some terminals (like XTerm) allow full 24-bit RGB color
    specifications using an extension to the regular ANSI color
    scheme. Let's allow users to specify hex RGB colors,
    enabling the all-important feature of hot pink ref
      git log --format="%h%C(#ff69b4)%d%C(reset) %s"
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
  3. @peff @gitster

    parse_color: refactor color storage

    peff authored gitster committed
    When we parse a color name like "red" into its ANSI color
    value, we pack the storage into a single int that may take
    on many values:
      1. If it's "-2", no value has been specified.
      2. If it's "-1", the value is "normal" (i.e., no color).
      3. If it's 0 through 7, the value is a standard ANSI
      4. If it's larger (up to 255), it is a 256-color extended
    Given these magic numbers, it is often hard to see what is
    going on in the code. Let's refactor this into a struct with
    a flag that tells which scheme we are using, along with a
    numeric value. This is more verbose, but should hopefully be
    simpler to follow. It will also allow us to easily add
    support for more schemes, like 24-bit RGB values.
    The result is also slightly less efficient to store, but
    that's OK; we only store this intermediate state during the
    parse, after which we write out the actual ANSI bytes.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Commits on Oct 14, 2014
  1. @peff @gitster

    color_parse: do not mention variable name in error message

    peff authored gitster committed
    Originally the color-parsing function was used only for
    config variables. It made sense to pass the variable name so
    that the die() message could be something like:
      $ git -c color.branch.plain=bogus branch
      fatal: bad color value 'bogus' for variable 'color.branch.plain'
    These days we call it in other contexts, and the resulting
    error messages are a little confusing:
      $ git log --pretty='%C(bogus)'
      fatal: bad color value 'bogus' for variable '--pretty format'
      $ git config --get-color bogus
      fatal: bad color value 'bogus' for variable 'command line'
    This patch teaches color_parse to complain only about the
    value, and then return an error code. Config callers can
    then propagate that up to the config parser, which mentions
    the variable name. Other callers can provide a custom
    message. After this patch these three cases now look like:
      $ git -c color.branch.plain=bogus branch
      error: invalid color value: bogus
      fatal: unable to parse 'color.branch.plain' from command-line config
      $ git log --pretty='%C(bogus)'
      error: invalid color value: bogus
      fatal: unable to parse --pretty format
      $ git config --get-color bogus
      error: invalid color value: bogus
      fatal: unable to parse default color value
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Commits on Aug 19, 2011
  1. @peff @gitster

    want_color: automatically fallback to color.ui

    peff authored gitster committed
    All of the "do we want color" flags default to -1 to
    indicate that we don't have any color configured. This value
    is handled in one of two ways:
      1. In porcelain, we check early on whether the value is
         still -1 after reading the config, and set it to the
         value of color.ui (which defaults to 0).
      2. In plumbing, it stays untouched as -1, and want_color
         defaults it to off.
    This works fine, but means that every porcelain has to check
    and reassign its color flag. Now that want_color gives us a
    place to put this check in a single spot, we can do that,
    simplifying the calling code.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
  2. @peff @gitster

    diff: don't load color config in plumbing

    peff authored gitster committed
    The diff config callback is split into two functions: one
    which loads "ui" config, and one which loads "basic" config.
    The former chains to the latter, as the diff UI config is a
    superset of the plumbing config.
    The color.diff variable is only loaded in the UI config.
    However, the basic config actually chains to
    git_color_default_config, which loads color.ui. This doesn't
    actually cause any bugs, because the plumbing diff code does
    not actually look at the value of color.ui.
    However, it is somewhat nonsensical, and it makes it
    difficult to refactor the color code. It probably came about
    because there is no git_color_config to load only color
    config, but rather just git_color_default_config, which
    loads color config and chains to git_default_config.
    This patch splits out the color-specific portion of
    git_color_default_config so that the diff UI config can call
    it directly. This is perhaps better explained by the
    chaining of callbacks. Before we had:
        -> git_diff_basic_config
          -> git_color_default_config
            -> git_default_config
    Now we have:
        -> git_color_config
        -> git_diff_basic_config
          -> git_default_config
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
  3. @peff @gitster

    color: delay auto-color decision until point of use

    peff authored gitster committed
    When we read a color value either from a config file or from
    the command line, we use git_config_colorbool to convert it
    from the tristate always/never/auto into a single yes/no
    boolean value.
    This has some timing implications with respect to starting
    a pager.
    If we start (or decide not to start) the pager before
    checking the colorbool, everything is fine. Either isatty(1)
    will give us the right information, or we will properly
    check for pager_in_use().
    However, if we decide to start a pager after we have checked
    the colorbool, things are not so simple. If stdout is a tty,
    then we will have already decided to use color. However, the
    user may also have configured color.pager not to use color
    with the pager. In this case, we need to actually turn off
    color. Unfortunately, the pager code has no idea which color
    variables were turned on (and there are many of them
    throughout the code, and they may even have been manipulated
    after the colorbool selection by something like "--color" on
    the command line).
    This bug can be seen any time a pager is started after
    config and command line options are checked. This has
    affected "git diff" since 89d07f7 (diff: don't run pager if
    user asked for a diff style exit code, 2007-08-12). It has
    also affect the log family since 1fda91b (Fix 'git log'
    early pager startup error case, 2010-08-24).
    This patch splits the notion of parsing a colorbool and
    actually checking the configuration. The "use_color"
    variables now have an additional possible value,
    GIT_COLOR_AUTO. Users of the variable should use the new
    "want_color()" wrapper, which will lazily determine and
    cache the auto-color decision.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Commits on Aug 18, 2011
  1. @peff @gitster

    git_config_colorbool: refactor stdout_is_tty handling

    peff authored gitster committed
    Usually this function figures out for itself whether stdout
    is a tty. However, it has an extra parameter just to allow
    git-config to override the auto-detection for its
    --get-colorbool option.
    Instead of an extra parameter, let's just use a global
    variable. This makes calling easier in the common case, and
    will make refactoring the colorbool code much simpler.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Commits on Dec 10, 2010
  1. @peff @gitster

    default color.status.branch to "same as header"

    peff authored gitster committed
    This gives it the same behavior as we had prior to 1d28232
    (status: show branchname with a configurable color).
    To do this we need the concept of a "NIL" color, which is
    provided by color.[ch]. The implementation is very simple;
    in particular, there are no precautions taken against code
    accidentally printing the NIL. This should be fine in
    practice because:
      1. You can't input a NIL color in the config, so it must
         come from the in-code defaults. Which means it is up
         the client code to handle the NILs it defines.
      2. If we do ever print a NIL, it will be obvious what the
         problem is, and the bug can be fixed.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Commits on Jan 18, 2009
  1. @peff @gitster

    color: make it easier for non-config to parse color specs

    peff authored gitster committed
    We have very featureful color-parsing routines which are
    used for color.diff.* and other options. Let's make it
    easier to use those routines from other parts of the code.
    This patch adds a color_parse_mem() helper function which
    takes a length-bounded string instead of a NUL-terminated
    one. While the helper is only a few lines long, it is nice
    to abstract this out so that:
     - callers don't forget to free() the temporary buffer
     - right now, it is implemented in terms of color_parse().
       But it would be more efficient to reverse this and
       implement color_parse in terms of color_parse_mem.
    This also changes the error string for an invalid color not
    to mention the word "config", since it is not always
    appropriate (and when it is, the context is obvious since
    the offending config variable is given).
    Finally, while we are in the area, we clean up the parameter
    names in the declaration of color_parse; the var and value
    parameters were reversed from the actual implementation.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Commits on Dec 11, 2007
  1. @peff @gitster

    Support GIT_PAGER_IN_USE environment variable

    peff authored gitster committed
    When deciding whether or not to turn on automatic color
    support, git_config_colorbool checks whether stdout is a
    tty. However, because we run a pager, if stdout is not a
    tty, we must check whether it is because we started the
    pager. This used to be done by checking the pager_in_use
    This variable was set only when the git program being run
    started the pager; there was no way for an external program
    running git indicate that it had already started a pager.
    This patch allows a program to set GIT_PAGER_IN_USE to a
    true value to indicate that even though stdout is not a tty,
    it is because a pager is being used.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Commits on Sep 8, 2006
  1. @peff

    Move color option parsing out of diff.c and into color.[ch]

    peff authored Junio C Hamano committed
    The intent is to lib-ify colorizing code so it can be reused.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Something went wrong with that request. Please try again.