1. 03 Aug, 2018 1 commit
  2. 06 May, 2018 1 commit
    • Johannes Schindelin's avatar
      Replace all die("BUG: ...") calls by BUG() ones · 033abf97
      Johannes Schindelin authored
      In d8193743 (usage.c: add BUG() function, 2017-05-12), a new macro
      was introduced to use for reporting bugs instead of die(). It was then
      subsequently used to convert one single caller in 588a538a
      (setup_git_env: convert die("BUG") to BUG(), 2017-05-12).
      
      The cover letter of the patch series containing this patch
      (cf 20170513032414.mfrwabt4hovujde2@sigill.intra.peff.net) is not
      terribly clear why only one call site was converted, or what the plan
      is for other, similar calls to die() to report bugs.
      
      Let's just convert all remaining ones in one fell swoop.
      
      This trick was performed by this invocation:
      
      	sed -i 's/die("BUG: /BUG("/g' $(git grep -l 'die("BUG' \*.c)
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      033abf97
  3. 24 Apr, 2018 1 commit
    • Johannes Schindelin's avatar
      color: introduce support for colorizing stderr · 295d949c
      Johannes Schindelin authored
      So far, we only ever asked whether stdout wants to be colorful. In the
      upcoming patches, we will want to make push errors more prominent, which
      are printed to stderr, though.
      
      So let's refactor the want_color() function into a want_color_fd()
      function (which expects to be called with fd == 1 or fd == 2 for stdout
      and stderr, respectively), and then define the macro `want_color()` to
      use the want_color_fd() function.
      
      And then also add a macro `want_color_stderr()`, for convenience and
      for documentation.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      295d949c
  4. 13 Feb, 2018 1 commit
  5. 04 Dec, 2017 1 commit
  6. 17 Oct, 2017 2 commits
    • Jeff King's avatar
      Revert "color: check color.ui in git_default_config()" · 33c643bb
      Jeff King authored
      This reverts commit 136c8c8b.
      
      That commit was trying to address a bug caused by 4c7f1819
      (make color.ui default to 'auto', 2013-06-10), in which
      plumbing like diff-tree defaulted to "auto" color, but did
      not respect a "color.ui" directive to disable it.
      
      But it also meant that we started respecting "color.ui" set
      to "always". This was a known problem, but 4c7f1819 argued
      that nobody ought to be doing that. However, that turned out
      to be wrong, and we got a number of bug reports related to
      "add -p" regressing in v2.14.2.
      
      Let's revert 136c8c8b, fixing the regression to "add -p".
      This leaves the problem from 4c7f1819 unfixed, but:
      
        1. It's a pretty obscure problem in the first place. I
           only noticed it while working on the color code, and we
           haven't got a single bug report or complaint about it.
      
        2. We can make a more moderate fix on top by respecting
           "never" but not "always" for plumbing commands. This
           is just the minimal fix to go back to the working state
           we had before v2.14.2.
      
      Note that this isn't a pure revert. We now have a test in
      t3701 which shows off the "add -p" regression. This can be
      flipped to success.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      33c643bb
    • Jeff King's avatar
      Revert "color: make "always" the same as "auto" in config" · 2c1acdf6
      Jeff King authored
      This reverts commit 6be4595e.
      
      That commit weakened the "always" setting of color config so
      that it acted as "auto". This was meant to solve regressions
      in v2.14.2 in which setting "color.ui=always" in the on-disk
      config broke scripts like add--interactive, because the
      plumbing diff commands began to generate color output.
      
      This was due to 136c8c8b (color: check color.ui in
      git_default_config(), 2017-07-13), which was in turn trying
      to fix issues caused by 4c7f1819 (make color.ui default to
      'auto', 2013-06-10). But in weakening "always", we created
      even more problems, as people expect to be able to use "git
      -c color.ui=always" to force color (especially because some
      commands don't have their own --color flag). We can fix that
      by special-casing the command-line "-c", but now things are
      getting pretty confusing.
      
      Instead of piling hacks upon hacks, let's start peeling off
      the hacks. The first step is dropping the weakening of
      "always", which this revert does.
      
      Note that we could actually revert the whole series merged
      in by da15b78e. Most of that
      series consists of preparations to the tests to handle the
      weakening of "-c color.ui=always". But it's worth keeping
      for a few reasons:
      
        - there are some other preparatory cleanups, like
          e433749d (test-terminal: set TERM=vt100, 2017-10-03)
      
        - it adds "--color" options more consistently in
          0c88bf50 (provide --color option for all ref-filter
          users, 2017-10-03)
      
        - some of the cases dropping "-c" end up being more robust
          and realistic tests, as in 01c94e90 (t7508: use
          test_terminal for color output, 2017-10-03)
      
        - the preferred tool for overriding config is "--color",
          and we should be modeling that consistently
      
      We can individually revert the few commits necessary to
      restore some useful tests (which will be done on top of this
      patch).
      
      Note that this isn't a pure revert; we'll keep the test
      added in t3701, but mark it as failure for now.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      2c1acdf6
  7. 04 Oct, 2017 1 commit
    • Jeff King's avatar
      color: make "always" the same as "auto" in config · 6be4595e
      Jeff King authored
      It can be handy to use `--color=always` (or it's synonym
      `--color`) on the command-line to convince a command to
      produce color even if it's stdout isn't going to the
      terminal or a pager.
      
      What's less clear is whether it makes sense to set config
      variables like color.ui to `always`. For a one-shot like:
      
        git -c color.ui=always ...
      
      it's potentially useful (especially if the command doesn't
      directly support the `--color` option). But setting `always`
      in your on-disk config is much muddier, as you may be
      surprised when piped commands generate colors (and send them
      to whatever is consuming the pipe downstream).
      
      Some people have done this anyway, because:
      
        1. The documentation for color.ui makes it sound like
           using `always` is a good idea, when you almost
           certainly want `auto`.
      
        2. Traditionally not every command (and especially not
           plumbing) respected color.ui in the first place. So
           the confusion came up less frequently than it might
           have.
      
      The situation changed in 136c8c8b (color: check color.ui
      in git_default_config(), 2017-07-13), which negated point
      (2): now scripts using only plumbing commands (like
      add-interactive) are broken by this setting.
      
      That commit was fixing real issues (e.g., by making
      `color.ui=never` work, since `auto` is the default), so we
      don't want to just revert it.  We could turn `always` into a
      noop in plumbing commands, but that creates a hard-to-explain
      inconsistency between the plumbing and other commands.
      
      Instead, let's just turn `always` into `auto` for all config.
      This does break the "one-shot" config shown above, but again,
      we're probably better to have simple and consistent rules than
      to try to special-case command-line config.
      
      There is one place where `always` should retain its meaning:
      on the command line, `--color=always` should continue to be
      the same as `--color`, overriding any isatty checks. Since the
      command-line parser also depends on git_config_colorbool(), we
      can use the existence of the "var" string to deterine whether
      we are serving the command-line or the config.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      6be4595e
  8. 23 Aug, 2017 1 commit
    • Martin Ågren's avatar
      ThreadSanitizer: add suppressions · 6cdf8a79
      Martin Ågren authored
      Add a file .tsan-suppressions and list two functions in it: want_color()
      and transfer_debug(). Both of these use the pattern
      
      	static int foo = -1;
      	if (foo < 0)
      		foo = bar();
      
      where bar always returns the same non-negative value. This can cause
      ThreadSanitizer to diagnose a race when foo is written from two threads.
      That is indeed a race, although it arguably doesn't matter in practice
      since it's always the same value that is written.
      
      Add NEEDSWORK-comments to the functions so that this problem is not
      forever swept way under the carpet.
      
      The suppressions-file is used by setting the environment variable
      TSAN_OPTIONS to, e.g., "suppressions=$(pwd)/.tsan-suppressions". Observe
      that relative paths such as ".tsan-suppressions" might not work.
      Signed-off-by: 's avatarMartin Ågren <martin.agren@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      6cdf8a79
  9. 13 Jul, 2017 1 commit
    • Jeff King's avatar
      color: check color.ui in git_default_config() · 136c8c8b
      Jeff King authored
      Back in prehistoric times, our decision on whether or not to
      show color by default relied on using a config callback that
      either did or didn't load color config like color.diff.
      When we introduced color.ui, we put it in the same boat:
      commands had to manually respect it by using git_color_config()
      or its git_color_default_config() convenience wrapper.
      
      But in 4c7f1819 (make color.ui default to 'auto',
      2013-06-10), that changed. Since then, we default color.ui
      to auto in all programs, meaning that even plumbing commands
      like "git diff-tree --pretty" might colorize the output.
      Nobody seems to have complained in the intervening years,
      presumably because the "is stdout a tty" check does a good
      job of catching the right cases.
      
      But that leaves an interesting curiosity: color.ui defaults
      to auto even in plumbing, but you can't actually _disable_
      the color via config. So if you really hate color and set
      "color.ui" to false, diff-tree will still show color (but
      porcelain like git-diff won't).  Nobody noticed that either,
      probably because very few people disable color.
      
      One could argue that the plumbing should _always_ disable
      color unless an explicit --color option is given on the
      command line. But in practice, this creates a lot of
      complications for scripts which do want plumbing to show
      user-visible output. They can't just pass "--color" blindly;
      they need to check the user's config and decide what to
      send.
      
      Given that nobody has complained about the current behavior,
      let's assume it's a good path, and follow it to its
      conclusion: supporting color.ui everywhere.
      
      Note that you can create havoc by setting color.ui=always in
      your config, but that's more or less already the case. We
      could disallow it entirely, but it is handy for one-offs
      like:
      
        git -c color.ui=always foo >not-a-tty
      
      when "foo" does not take a --color option itself.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      136c8c8b
  10. 15 Jun, 2017 1 commit
  11. 01 Feb, 2017 1 commit
    • Jeff King's avatar
      color_parse_mem: allow empty color spec · 55cccf4b
      Jeff King authored
      Prior to c2f41bf5 (color.c: fix color_parse_mem() with
      value_len == 0, 2017-01-19), the empty string was
      interpreted as a color "reset". This was an accidental
      outcome, and that commit turned it into an error.
      
      However, scripts may pass the empty string as a default
      value to "git config --get-color" to disable color when the
      value is not defined. The git-add--interactive script does
      this. As a result, the script is unusable since c2f41bf5
      unless you have color.diff.plain defined (if it is defined,
      then we don't parse the empty default at all).
      
      Our test scripts didn't notice the recent breakage because
      they run without a terminal, and thus without color. They
      never hit this code path at all. And nobody noticed the
      original buggy "reset" behavior, because it was effectively
      a noop.
      
      Let's fix the code to have an empty color name produce an
      empty sequence of color codes. The tests need a few fixups:
      
        - we'll add a new test in t4026 to cover this case. But
          note that we need to tweak the color() helper. While
          we're there, let's factor out the literal ANSI ESC
          character. Otherwise it makes the diff quite hard to
          read.
      
        - we'll add a basic sanity-check in t4026 that "git add
          -p" works at all when color is enabled. That would have
          caught this bug, as well as any others that are specific
          to the color code paths.
      
        - 73c727d6 (log --graph: customize the graph lines with
          config log.graphColors, 2017-01-19) added a test to
          t4202 that checks some "invalid" graph color config.
          Since ",, blue" before yielded only "blue" as valid, and
          now yields "empty, empty, blue", we don't match the
          expected output.
      
          One way to fix this would be to change the expectation
          to the empty color strings. But that makes the test much
          less interesting, since we show only two graph lines,
          both of which would be colorless.
      
          Since the empty-string case is now covered by t4026,
          let's remove them entirely here. They're just in the way
          of the primary thing the test is supposed to be
          checking.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      55cccf4b
  12. 19 Jan, 2017 2 commits
  13. 31 Aug, 2016 1 commit
    • Jeff King's avatar
      color_parse_mem: initialize "struct color" temporary · 3e1952ed
      Jeff King authored
      Compiling color.c with gcc 6.2.0 using -O3 produces some
      -Wmaybe-uninitialized false positives:
      
          color.c: In function ‘color_parse_mem’:
          color.c:189:10: warning: ‘bg.blue’ may be used uninitialized in this function [-Wmaybe-uninitialized]
             out += xsnprintf(out, len, "%c8;2;%d;%d;%d", type,
                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                c->red, c->green, c->blue);
                ~~~~~~~~~~~~~~~~~~~~~~~~~~
          color.c:208:15: note: ‘bg.blue’ was declared here
            struct color bg = { COLOR_UNSPECIFIED };
                         ^~
          [ditto for bg.green, bg.red, fg.blue, etc]
      
      This is doubly confusing, because the declaration shows it
      being initialized! Even though we do not explicitly
      initialize the color components, an incomplete initializer
      sets the unmentioned members to zero.
      
      What the warning doesn't show is that we later do this:
      
        struct color c;
        if (!parse_color(&c, ...)) {
                if (fg.type == COLOR_UNSPECIFIED)
                      fg = c;
                ...
        }
      
      gcc is clever enough to realize that a struct assignment
      from an uninitialized variable taints the destination. But
      unfortunately it's _not_ clever enough to realize that we
      only look at those members when type is set to COLOR_RGB, in
      which case they are always initialized.
      
      With -O2, gcc does not look into parse_color() and must
      assume that "c" emerges fully initialized. With -O3, it
      inlines parse_color(), and learns just enough to get
      confused.
      
      We can silence the false positive by initializing the
      temporary "c". This also future-proofs us against
      violating the type assumptions (the result would probably
      still be buggy, but in a deterministic way).
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      3e1952ed
  14. 23 Jun, 2016 4 commits
    • Jeff King's avatar
      color: support strike-through attribute · 9dc3515c
      Jeff King authored
      This is the only remaining attribute that is commonly
      supported (at least by xterm) that we don't support. Let's
      add it for completeness.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      9dc3515c
    • Jeff King's avatar
      color: support "italic" attribute · 54590a0e
      Jeff King authored
      We already support bold, underline, and similar attributes.
      Let's add italic to the mix.  According to the Wikipedia
      page on ANSI colors, this attribute is "not widely
      supported", but it does seem to work on my xterm.
      
      We don't have to bump the maximum color size because we were
      already over-allocating it (but we do adjust the comment
      appropriately).
      Requested-by: 's avatarSimon Courtois <scourtois@cubyx.fr>
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      54590a0e
    • Jeff King's avatar
      color: allow "no-" for negating attributes · 5621068f
      Jeff King authored
      Using "no-bold" rather than "nobold" is easier to read and
      more natural to type (to me, anyway, even though I was the
      person who introduced "nobold" in the first place). It's
      easy to allow both.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      5621068f
    • Jeff King's avatar
      color: refactor parse_attr · df8e472c
      Jeff King authored
      The list of attributes we recognize is a bit unwieldy, as we
      actually have two arrays that must be kept in sync. Instead,
      let's have a single array-of-struct to represent our
      mapping. That means we can never have an accident that
      causes us to read off the end of an array, and it makes
      diffs for adding new attributes much easier to read.
      
      This also makes it easy to handle the "no" cases without
      having to repeat each attribute (this shortens the list,
      making it easier to read, but also also cuts the size of our
      linear search in half). Technically this makes it impossible
      for us to add an attribute that starts with "no" (we could
      confuse "nobody" for the negation of "body"), but since this
      is a constrained set of attributes, that's OK.
      
      Since we can also store the length of each name in the
      struct, that makes it easy for us to avoid reading past the
      "len" parameter given to us (though in practice it was not a
      bug, since all of our current callers are interested in a
      subset of a NUL-terminated buffer, not a true undelimited
      range of memory).
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      df8e472c
  15. 05 Oct, 2015 2 commits
    • Jeff King's avatar
      color: add color_set helper for copying raw colors · 7ce4fb94
      Jeff King authored
      To set up default colors, we sometimes strcpy() from the
      default string literals into our color buffers. This isn't a
      bug (assuming the destination is COLOR_MAXLEN bytes), but
      makes it harder to audit the code for problematic strcpy
      calls.
      
      Let's introduce a color_set which copies under the
      assumption that there are COLOR_MAXLEN bytes in the
      destination (of course you can call it on a smaller buffer,
      so this isn't providing a huge amount of safety, but it's
      more convenient than calling xsnprintf yourself).
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      7ce4fb94
    • Jeff King's avatar
      color: add overflow checks for parsing colors · cbc8feea
      Jeff King authored
      Our color parsing is designed to never exceed COLOR_MAXLEN
      bytes. But the relationship between that hand-computed
      number and the parsing code is not at all obvious, and we
      merely hope that it has been computed correctly for all
      cases.
      
      Let's mark the expected "end" pointer for the destination
      buffer and make sure that we do not exceed it.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      cbc8feea
  16. 20 Jan, 2015 1 commit
  17. 09 Dec, 2014 1 commit
    • Jeff King's avatar
      parse_color: drop COLOR_BACKGROUND macro · 71b59849
      Jeff King authored
      Commit 695d95df (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 695d95df 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: 's avatarJohannes Sixt <j6t@kdbg.org>
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      71b59849
  18. 20 Nov, 2014 3 commits
    • Jeff King's avatar
      parse_color: recognize "no$foo" to clear the $foo attribute · ff40d185
      Jeff King authored
      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
      example:
      
        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: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      ff40d185
    • Jeff King's avatar
      parse_color: support 24-bit RGB values · 17a4be26
      Jeff King authored
      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
      decorations:
      
        git log --format="%h%C(#ff69b4)%d%C(reset) %s"
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      17a4be26
    • Jeff King's avatar
      parse_color: refactor color storage · 695d95df
      Jeff King authored
      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
           color.
      
        4. If it's larger (up to 255), it is a 256-color extended
           value.
      
      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: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      695d95df
  19. 14 Oct, 2014 1 commit
    • Jeff King's avatar
      color_parse: do not mention variable name in error message · f6c5a296
      Jeff King authored
      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 foo.bar 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 foo.bar bogus
        error: invalid color value: bogus
        fatal: unable to parse default color value
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      f6c5a296
  20. 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: 's avatarMatthieu Moy <Matthieu.Moy@imag.fr>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      4c7f1819
  21. 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: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's 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: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's 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: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      daa0c3d9
  22. 18 Aug, 2011 1 commit
  23. 05 Apr, 2011 1 commit
  24. 08 Mar, 2011 2 commits
  25. 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: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      148135fc
  26. 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: 's avatarThomas Rast <trast@student.ethz.ch>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      882749a0
  27. 07 Mar, 2010 1 commit
  28. 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: 's avatarJunio C Hamano <gitster@pobox.com>
      73e9da01
  29. 14 Feb, 2009 1 commit