kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Johannes Schindelin	3d0a83382f	color.h: remove obsolete comment about limitations on Windows Originally, ANSI color sequences were supported on Windows only by overriding the printf() and fprintf() functions, as mentioned in `e7821d7` (Add a notice that only certain functions can print color escape codes, 2009-11-27). As of `eac14f8` (Win32: Thread-safe windows console output, 2012-01-14), however, this is no longer the case, as the ANSI color sequence support code needed to be replaced with a thread-safe version, one side effect being that stdout and stderr handled no matter which function is used to write to it. So let's just remove the comment that is now obsolete. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Jeff King	9dc3515cf0	color: support strike-through attribute 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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Jeff King	54590a0eda	color: support "italic" attribute 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: Simon Courtois <scourtois@cubyx.fr> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Jeff King	0111681ecf	color: fix max-size comment We use fixed-size buffers for colors, because we know our parsing cannot grow beyond a particular bound. However, our comment description has two issues: 1. It has the description in two forms: a short one, and one with more explanation. Over time the latter has been updated, but the former has not. Let's just drop the short one (after making sure everything it says is in the long one). 2. As of `ff40d18` (parse_color: recognize "no$foo" to clear the $foo attribute, 2014-11-20), the per-attribute size bumped to "3" (because "nobold" is actually "21;"). But that's not quite enough, as somebody may use both "bold" and "nobold", requiring 5 characters. This wasn't a problem for the final count, because we over-estimated in other ways, but let's clarify how we got to the final number. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Jeff King	7ce4fb948c	color: add color_set helper for copying raw colors 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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Jeff King	ff40d185d2	parse_color: recognize "no$foo" to clear the $foo attribute 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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	10 years ago
Jeff King	17a4be2606	parse_color: support 24-bit RGB values 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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	10 years ago
Jeff King	f6c5a2968c	color_parse: do not mention variable name in error message 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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	10 years ago
Jeff King	c9bfb95348	want_color: automatically fallback to color.ui 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>	14 years ago
Jeff King	3e1dd17a89	diff: don't load color config in plumbing 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>	14 years ago
Jeff King	daa0c3d971	color: delay auto-color decision until point of use 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>	14 years ago
Jeff King	e269eb7946	git_config_colorbool: refactor stdout_is_tty handling 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>	14 years ago
Dan McGee	7cd52b5b4b	Share color list between graph and show-branch This also adds the new colors to show-branch that were added a while back for graph output. Signed-off-by: Dan McGee <dpmcgee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Jonathan Nieder	becbdae82b	wt-status: add helpers for printing wt-status lines 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 <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Jonathan Nieder	e0335fcdad	wt-status: add helpers for printing wt-status lines 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 <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Jeff King	148135fc24	default color.status.branch to "same as header" 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>	14 years ago
Thomas Rast	882749a04f	diff: add --word-diff option that generalizes --color-words 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: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Junio C Hamano	8b124135a9	color: allow multiple attributes 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. [diff.color] old = red reverse bold Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Mark Lodato	758df17ab0	Add GIT_COLOR_BOLD_* and GIT_COLOR_BG_* Add GIT_COLOR_BOLD_* macros to set both bold and the color in one sequence. This saves two characters of output ("ESC [ m", minus ";") and makes the code more readable. Add the remaining GIT_COLOR_BG_* macros to make the list complete. The white and black colors are not included since they look bad on most terminals. Signed-off-by: Mark Lodato <lodatom@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Johannes Sixt	e7821d73bd	Add a notice that only certain functions can print color escape codes We emulate color escape codes on Windows by overriding printf, fprintf, and fputs. Warn developers that these are the only functions that can be used to print them. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Tarmigan Casebolt	28bea9e534	Check the format of more printf-type functions We already have these checks in many printf-type functions that have prototypes which are in header files. Add these same checks to some more prototypes in header functions and to static functions in .c files. cc: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Allan Caffee	427fc5b888	graph API: Added logic for colored edges Modified the graph drawing logic to colorize edges based on parent-child relationships similiarly to gitk. Signed-off-by: Allan Caffee <allan.caffee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Arjen Laarhoven	dc6ebd4cc5	Clean up use of ANSI color sequences Remove the literal ANSI escape sequences and replace them by readable constants. Signed-off-by: Arjen Laarhoven <arjen@yaph.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Jeff King	5ef8d77a75	color: make it easier for non-config to parse color specs 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>	16 years ago
Johannes Schindelin	07b57e90f7	Add color_fwrite_lines(), a function coloring each line individually 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 <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Johannes Schindelin	ef90d6d420	Provide git_config with a callback-data parameter 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 <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Matthias Kestenholz	6b2f2d9805	Add color.ui variable which globally enables colorization if set Signed-off-by: Matthias Kestenholz <mk@spinlock.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Junio C Hamano	0f6f5a4022	git config --get-colorbool 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 <gitster@pobox.com>	17 years ago
Kristian Høgsberg	f26a001226	Enable wt-status output to a given FILE pointer. Still defaults to stdout, but you can now override wt_status.fp after calling wt_status_prepare(). Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Jeff King	7c92fe0eaa	Move color option parsing out of diff.c and into color.[ch] 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>	19 years ago

34 Commits (6610af872f6494a061780ec738c8713a034b848b)