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: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NMatthias Kestenholz <mk@spinlock.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Numeric color only worked if it was at end of line.
Noticed by Chris Larson <clarson@kergoth.com>.
Signed-off-by: NTimo Hirvonen <tihirvon@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NJunio C Hamano <gitster@pobox.com>

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: NJunio C Hamano <gitster@pobox.com>

Still defaults to stdout, but you can now override wt_status.fp after
calling wt_status_prepare().
Signed-off-by: NKristian Høgsberg <krh@redhat.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NJunio C Hamano <junkio@cox.net>

The intent is to lib-ify colorizing code so it can be reused.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>