- 11 6月, 2013 1 次提交
-
-
由 Matthieu Moy 提交于
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: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 8月, 2011 3 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 8月, 2011 1 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 05 4月, 2011 1 次提交
-
-
由 Dan McGee 提交于
This also adds the new colors to show-branch that were added a while back for graph output. Signed-off-by: NDan McGee <dpmcgee@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 3月, 2011 2 次提交
-
-
由 Jonathan Nieder 提交于
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: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
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: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 12月, 2010 1 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 4月, 2010 1 次提交
-
-
由 Thomas Rast 提交于
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: NThomas Rast <trast@student.ethz.ch> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 3月, 2010 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 19 2月, 2010 1 次提交
-
-
由 Mark Lodato 提交于
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: NMark Lodato <lodatom@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 2月, 2009 1 次提交
-
-
由 Arjen Laarhoven 提交于
Remove the literal ANSI escape sequences and replace them by readable constants. Signed-off-by: NArjen Laarhoven <arjen@yaph.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 1月, 2009 1 次提交
-
-
由 René Scharfe 提交于
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>
-
- 18 1月, 2009 2 次提交
-
-
由 Jeff King 提交于
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>
-
由 Johannes Schindelin 提交于
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>
-
- 15 5月, 2008 1 次提交
-
-
由 Johannes Schindelin 提交于
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>
-
- 18 2月, 2008 1 次提交
-
-
由 Matthias Kestenholz 提交于
Signed-off-by: NMatthias Kestenholz <mk@spinlock.ch> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 2月, 2008 1 次提交
-
-
由 Timo Hirvonen 提交于
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>
-
- 11 12月, 2007 1 次提交
-
-
由 Jeff King 提交于
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>
-
- 06 12月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
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>
-
- 29 11月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
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>
-
- 20 9月, 2007 1 次提交
-
-
由 Kristian Høgsberg 提交于
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>
-
- 21 12月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
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>
-
- 09 9月, 2006 1 次提交
-
-
由 Jeff King 提交于
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>
-