Skip to content
This repository


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Aug 19, 2011

  1. Jeff King

    want_color: automatically fallback to color.ui

    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 <>
    authored August 17, 2011 gitster committed August 19, 2011
  2. Jeff King

    diff: don't load color config in plumbing

    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 <>
    authored August 17, 2011 gitster committed August 19, 2011
  3. Jeff King

    color: delay auto-color decision until point of use

    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 <>
    authored August 17, 2011 gitster committed August 19, 2011

Aug 18, 2011

  1. Jeff King

    git_config_colorbool: refactor stdout_is_tty handling

    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 <>
    authored August 17, 2011 gitster committed August 18, 2011

Apr 05, 2011

  1. Dan McGee

    Share color list between graph and show-branch

    This also adds the new colors to show-branch that were added a while
    back for graph output.
    Signed-off-by: Dan McGee <>
    Signed-off-by: Junio C Hamano <>
    authored April 05, 2011 gitster committed April 04, 2011

Mar 08, 2011

  1. jrn

    wt-status: add helpers for printing wt-status lines

    Introduce status_printf{,_ln,_more} wrapper functions around
    color_vfprintf() which take care of adding "#" to the beginning of
    status lines automatically.  The semantics:
     - status_printf() is just like color_fprintf() but it adds a "# "
       at the beginning of each line of output;
     - status_printf_ln() is a convenience function that additionally
       adds "\n" at the end;
     - status_printf_more() is a variant of status_printf() used to
       continue lines that have already started.  It suppresses the "#" at
       the beginning of the first line.
    Helped-by: Junio C Hamano <>
    Signed-off-by: Jonathan Nieder <>
    Signed-off-by: Junio C Hamano <>
    authored February 25, 2011 gitster committed March 08, 2011

Dec 10, 2010

  1. Jeff King

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

    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 <>
    authored December 09, 2010 gitster committed December 10, 2010

Apr 14, 2010

  1. trast

    diff: add --word-diff option that generalizes --color-words

    This teaches the --color-words engine a more general interface that
    supports two new modes:
    * --word-diff=plain, inspired by the 'wdiff' utility (most similar to
      'wdiff -n <old> <new>'): uses delimiters [-removed-] and {+added+}
    * --word-diff=porcelain, which generates an ad-hoc machine readable
      - each diff unit is prefixed by [-+ ] and terminated by newline as
        in unified diff
      - newlines in the input are output as a line consisting only of a
        tilde '~'
    Both of these formats still support color if it is enabled, using it
    to highlight the differences.  --color-words becomes a synonym for
    --word-diff=color, which is the color-only format.  Also adds some
    compatibility/convenience options.
    Thanks to Junio C Hamano and Miles Bader for good ideas.
    Signed-off-by: Thomas Rast <>
    Signed-off-by: Junio C Hamano <>
    authored April 14, 2010 gitster committed April 14, 2010

Mar 20, 2010

  1. Junio C Hamano

    Merge branch 'jc/color-attrs'

    * jc/color-attrs:
      color: allow multiple attributes
    authored March 20, 2010

Mar 07, 2010

  1. Junio C Hamano

    color: allow multiple attributes

    In configuration files (and "git config --color" command line), we
    supported one and only one attribute after foreground and background
    color.  Accept combinations of attributes, e.g.
                old = red reverse bold
    Signed-off-by: Junio C Hamano <>
    authored February 27, 2010

Feb 19, 2010

  1. Mark Lodato

    Add an optional argument for --color options

    Make git-branch, git-show-branch, git-grep, and all the diff-based
    programs accept an optional argument <when> for --color.  The argument
    is a colorbool: "always", "never", or "auto".  If no argument is given,
    "always" is used;  --no-color is an alias for --color=never.  This makes
    the command-line interface consistent with other GNU tools, such as `ls'
    and `grep', and with the git-config color options.  Note that, without
    an argument, --color and --no-color work exactly as before.
    To implement this, two internal changes were made:
    1. Allow the first argument of git_config_colorbool() to be NULL,
       in which case it returns -1 if the argument isn't "always", "never",
       or "auto".
    2. Add OPT_COLOR_FLAG(), OPT__COLOR(), and parse_opt_color_flag_cb()
       to the option parsing library.  The callback uses
       git_config_colorbool(), so color.h is now a dependency
       of parse-options.c.
    Signed-off-by: Mark Lodato <>
    Signed-off-by: Junio C Hamano <>
    authored February 16, 2010 gitster committed February 18, 2010

Feb 14, 2009

  1. Arjen Laarhoven

    Clean up use of ANSI color sequences

    Remove the literal ANSI escape sequences and replace them by readable
    Signed-off-by: Arjen Laarhoven <>
    Signed-off-by: Junio C Hamano <>
    authored February 13, 2009 gitster committed February 13, 2009

Jan 26, 2009

  1. Junio C Hamano

    Merge branch 'js/diff-color-words'

    * js/diff-color-words:
      Change the spelling of "wordregex".
      color-words: Support diff.wordregex config option
      color-words: make regex configurable via attributes
      color-words: expand docs with precise semantics
      color-words: enable REG_NEWLINE to help user
      color-words: take an optional regular expression describing words
      color-words: change algorithm to allow for 0-character word boundaries
      color-words: refactor word splitting and use ALLOC_GROW()
      Add color_fwrite_lines(), a function coloring each line individually
    authored January 25, 2009

Jan 20, 2009

  1. Optimize color_parse_mem

    Commit 5ef8d77 implemented color_parse_mem, a function for
    parsing colors from a non-NUL-terminated string, by simply
    allocating a new NUL-terminated string and calling
    color_parse. This had a small but measurable speed impact on
    a user format that used the advanced color parsing. E.g.,
      # uses quick parsing
      $ time ./git log --pretty=tformat:'%Credfoo%Creset' >/dev/null
      real    0m0.673s
      user    0m0.652s
      sys     0m0.016s
      # uses color_parse_mem
      $ time ./git log --pretty=tformat:'%C(red)foo%C(reset)' >/dev/null
      real    0m0.692s
      user    0m0.660s
      sys     0m0.032s
    This patch implements color_parse_mem as the primary
    function, with color_parse as a wrapper for strings. This
    gives comparable timings to the first case above.
    Original patch by René. Commit message and debugging by Jeff
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
    authored January 19, 2009 gitster committed January 19, 2009

Jan 18, 2009

  1. Jeff King

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

    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 <>
    authored January 17, 2009 gitster committed January 17, 2009

Jan 17, 2009

  1. dscho

    Add color_fwrite_lines(), a function coloring each line individually

    We have to set the color before every line and reset it before every
    newline.  Add a function color_fwrite_lines() which does that for us.
    Signed-off-by: Johannes Schindelin <>
    Signed-off-by: Junio C Hamano <>
    authored January 17, 2009 gitster committed January 17, 2009

May 14, 2008

  1. dscho

    Provide git_config with a callback-data parameter

    git_config() only had a function parameter, but no callback data
    parameter.  This assumes that all callback functions only modify
    global variables.
    With this patch, every callback gets a void * parameter, and it is hoped
    that this will help the libification effort.
    Signed-off-by: Johannes Schindelin <>
    Signed-off-by: Junio C Hamano <>
    authored May 14, 2008 gitster committed May 14, 2008

Feb 18, 2008

  1. Matthias Kestenholz

    Add color.ui variable which globally enables colorization if set

    Signed-off-by: Matthias Kestenholz <>
    Signed-off-by: Junio C Hamano <>
    authored February 18, 2008 gitster committed February 18, 2008

Feb 06, 2008

  1. tihirvon

    Fix parsing numeric color values

    Numeric color only worked if it was at end of line.
    Noticed by Chris Larson <>.
    Signed-off-by: Timo Hirvonen <>
    Signed-off-by: Junio C Hamano <>
    authored February 06, 2008 gitster committed February 06, 2008

Dec 11, 2007

  1. Jeff King

    Support GIT_PAGER_IN_USE environment variable

    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 <>
    authored December 11, 2007 gitster committed December 11, 2007

Dec 06, 2007

  1. Junio C Hamano

    git config --get-colorbool

    This adds an option to help scripts find out color settings from
    the configuration file.
        git config --get-colorbool color.diff
    inspects color.diff variable, and exits with status 0 (i.e. success) if
    color is to be used.  It exits with status 1 otherwise.
    If a script wants "true"/"false" answer to the standard output of the
    command, it can pass an additional boolean parameter to its command
    line, telling if its standard output is a terminal, like this:
        git config --get-colorbool color.diff true
    When called like this, the command outputs "true" to its standard output
    if color is to be used (i.e. "color.diff" says "always", "auto", or
    "true"), and "false" otherwise.
    Signed-off-by: Junio C Hamano <>
    authored December 05, 2007

Nov 29, 2007

  1. Junio C Hamano

    "color.diff = true" is not "always" anymore.

    Too many people got burned by setting color.diff and color.status to
    true when they really should have set it to "auto".
    This makes only "always" to do the unconditional colorization, and
    change the meaning of "true" to the same as "auto": colorize only when
    we are talking to a terminal.
    Signed-off-by: Junio C Hamano <>
    authored November 26, 2007

Sep 19, 2007

  1. Enable wt-status output to a given FILE pointer.

    Still defaults to stdout, but you can now override wt_status.fp after
    calling wt_status_prepare().
    Signed-off-by: Kristian Høgsberg <>
    Signed-off-by: Junio C Hamano <>
    authored September 17, 2007 gitster committed September 19, 2007

Dec 20, 2006

  1. simplify inclusion of system header files.

    This is a mechanical clean-up of the way *.c files include
    system header files.
     (1) sources under compat/, platform sha-1 implementations, and
         xdelta code are exempt from the following rules;
     (2) the first #include must be "git-compat-util.h" or one of
         our own header file that includes it first (e.g. config.h,
         builtin.h, pkt-line.h);
     (3) system headers that are included in "git-compat-util.h"
         need not be included in individual C source files.
     (4) "git-compat-util.h" does not have to include subsystem
         specific header files (e.g. expat.h).
    Signed-off-by: Junio C Hamano <>
    authored December 19, 2006

Sep 08, 2006

  1. Jeff King

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

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