This project is mirrored from https://github.com/git/git. Updated .
  1. 10 Jun, 2013 1 commit
    • Matthieu Moy's avatar
      make color.ui default to 'auto' · 4c7f1819
      Matthieu Moy authored
      Most users seem to like having colors enabled, and colors can help
      beginners to understand the output of some commands (e.g. notice
      immediately the boundary between commits in the output of "git log").
      
      Many tutorials tell the users to set color.ui=auto as a very first step,
      which tend to indicate that color.ui=none is not the recommanded value,
      hence should not be the default.
      
      These tutorials would benefit from skipping this step and starting the
      real Git manipulations earlier. Other beginners do not know about
      color.ui=auto, and may not discover it by themselves, hence live with
      black&white outputs while they may have preferred colors.
      
      A few people (e.g. color-blind) prefer having no colors, but they can
      easily set color.ui=never for this (and googling "disable colors in git"
      already tells them how to do so), but this needs not occupy space in
      beginner-oriented documentations.
      
      A transition period with Git emitting a warning when color.ui is unset
      would be possible, but the discomfort of having the warning seems
      superior to the benefit: users may be surprised by the change, but not
      harmed by it.
      
      The default value is changed, and the documentation is reworded to
      mention "color.ui=false" first, since the primary use of color.ui after
      this change is to disable colors, not to enable it.
      Signed-off-by: default avatarMatthieu Moy <Matthieu.Moy@imag.fr>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      4c7f1819
  2. 19 Aug, 2011 3 commits
    • Jeff King's avatar
      want_color: automatically fallback to color.ui · c9bfb953
      Jeff King authored
      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: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      c9bfb953
    • Jeff King's avatar
      diff: don't load color config in plumbing · 3e1dd17a
      Jeff King authored
      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: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      3e1dd17a
    • Jeff King's avatar
      color: delay auto-color decision until point of use · daa0c3d9
      Jeff King authored
      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 89d07f75 (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 1fda91b5 (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: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      daa0c3d9
  3. 18 Aug, 2011 1 commit
  4. 05 Apr, 2011 1 commit
  5. 08 Mar, 2011 2 commits
  6. 10 Dec, 2010 1 commit
    • Jeff King's avatar
      default color.status.branch to "same as header" · 148135fc
      Jeff King authored
      This gives it the same behavior as we had prior to 1d282327
      (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: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      148135fc
  7. 14 Apr, 2010 1 commit
    • Thomas Rast's avatar
      diff: add --word-diff option that generalizes --color-words · 882749a0
      Thomas Rast authored
      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
        format:
        - 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: default avatarThomas Rast <trast@student.ethz.ch>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      882749a0
  8. 07 Mar, 2010 1 commit
  9. 19 Feb, 2010 1 commit
    • Mark Lodato's avatar
      Add an optional argument for --color options · 73e9da01
      Mark Lodato authored
      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's avatarMark Lodato <lodatom@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      73e9da01
  10. 14 Feb, 2009 1 commit
  11. 20 Jan, 2009 1 commit
    • René Scharfe's avatar
      Optimize color_parse_mem · 2c2dc7c8
      René Scharfe authored
      Commit 5ef8d77a 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
      King.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      2c2dc7c8
  12. 18 Jan, 2009 1 commit
    • Jeff King's avatar
      color: make it easier for non-config to parse color specs · 5ef8d77a
      Jeff King authored
      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: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      5ef8d77a
  13. 17 Jan, 2009 1 commit
  14. 14 May, 2008 1 commit
  15. 18 Feb, 2008 1 commit
  16. 06 Feb, 2008 1 commit
  17. 11 Dec, 2007 1 commit
    • Jeff King's avatar
      Support GIT_PAGER_IN_USE environment variable · 6e9af863
      Jeff King authored
      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
      variable.
      
      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: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      6e9af863
  18. 06 Dec, 2007 1 commit
    • Junio C Hamano's avatar
      git config --get-colorbool · 0f6f5a40
      Junio C Hamano authored
      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: default avatarJunio C Hamano <gitster@pobox.com>
      0f6f5a40
  19. 29 Nov, 2007 1 commit
  20. 19 Sep, 2007 1 commit
  21. 20 Dec, 2006 1 commit
    • Junio C Hamano's avatar
      simplify inclusion of system header files. · 85023577
      Junio C Hamano authored
      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: default avatarJunio C Hamano <junkio@cox.net>
      85023577
  22. 08 Sep, 2006 1 commit