Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
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 <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  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_ui_config
        -> git_diff_basic_config
          -> git_color_default_config
            -> git_default_config
    
    Now we have:
    
      git_diff_ui_config
        -> git_color_config
        -> git_diff_basic_config
          -> git_default_config
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  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 <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <peff@peff.net>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Something went wrong with that request. Please try again.