Skip to content
Commits on Aug 19, 2011
  1. @peff @gitster

    want_color: automatically fallback to color.ui

    peff committed with gitster
    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 committed with gitster
    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 committed with gitster
    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 committed with gitster
    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 Apr 5, 2011
  1. @toofishes @gitster

    Share color list between graph and show-branch

    toofishes committed with gitster
    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 <>
Commits on Mar 8, 2011
  1. @jrn @gitster

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

    jrn committed with gitster
    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 <>
Commits on Dec 10, 2010
  1. @peff @gitster

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

    peff committed with gitster
    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 Apr 14, 2010
  1. @trast @gitster

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

    trast committed with gitster
    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 <>
Commits on Mar 20, 2010
  1. @gitster

    Merge branch 'jc/color-attrs'

    gitster committed
    * jc/color-attrs:
      color: allow multiple attributes
Commits on Mar 7, 2010
  1. @gitster

    color: allow multiple attributes

    gitster committed
    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 <>
Commits on Feb 19, 2010
  1. @MarkLodato @gitster

    Add an optional argument for --color options

    MarkLodato committed with gitster
    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 <>
Commits on Feb 14, 2009
  1. @ArjenL @gitster

    Clean up use of ANSI color sequences

    ArjenL committed with gitster
    Remove the literal ANSI escape sequences and replace them by readable
    Signed-off-by: Arjen Laarhoven <>
    Signed-off-by: Junio C Hamano <>
Commits on Jan 26, 2009
  1. @gitster

    Merge branch 'js/diff-color-words'

    gitster committed
    * 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
Commits on Jan 20, 2009
  1. @gitster

    Optimize color_parse_mem

    René Scharfe committed with gitster
    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 <>
Commits on Jan 18, 2009
  1. @peff @gitster

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

    peff committed with gitster
    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 Jan 17, 2009
  1. @dscho @gitster

    Add color_fwrite_lines(), a function coloring each line individually

    dscho committed with gitster
    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 <>
Commits on May 14, 2008
  1. @dscho @gitster

    Provide git_config with a callback-data parameter

    dscho committed with gitster
    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 <>
Commits on Feb 18, 2008
  1. @matthiask @gitster

    Add color.ui variable which globally enables colorization if set

    matthiask committed with gitster
    Signed-off-by: Matthias Kestenholz <>
    Signed-off-by: Junio C Hamano <>
Commits on Feb 6, 2008
  1. @tihirvon @gitster

    Fix parsing numeric color values

    tihirvon committed with gitster
    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 <>
Commits on Dec 11, 2007
  1. @peff @gitster

    Support GIT_PAGER_IN_USE environment variable

    peff committed with gitster
    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 Dec 6, 2007
  1. @gitster

    git config --get-colorbool

    gitster committed
    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 <>
Commits on Nov 29, 2007
  1. @gitster

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

    gitster committed
    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 <>
Commits on Sep 19, 2007
  1. @gitster

    Enable wt-status output to a given FILE pointer.

    Kristian Høgsberg committed with gitster
    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 <>
Commits on Dec 20, 2006
  1. simplify inclusion of system header files.

    Junio C Hamano committed
    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 <>
Commits on Sep 8, 2006
  1. @peff

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

    peff committed with Junio C Hamano
    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.