git/grep.c, branch v2.3.3

Merge branch 'jk/blame-commit-label' into maint

2015-02-25T06:09:54Z

"git blame HEAD -- missing" failed to correctly say "HEAD" when it tried to say "No such path 'missing' in HEAD". * jk/blame-commit-label: blame.c: fix garbled error message use xstrdup_or_null to replace ternary conditionals builtin/commit.c: use xstrdup_or_null instead of envdup builtin/apply.c: use xstrdup_or_null instead of null_strdup git-compat-util: add xstrdup_or_null helper

use xstrdup_or_null to replace ternary conditionals

2015-01-13T18:05:48Z

This replaces "x ? xstrdup(x) : NULL" with xstrdup_or_null(x). The change is fairly mechanical, with the exception of resolve_refdup, which can eliminate a temporary variable. There are still a few hits grepping for "?.*xstrdup", but these are of slightly different forms and cannot be converted (e.g., "x ? xstrdup(x->foo) : NULL"). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'rs/grep-color-words'

2014-10-31T18:49:47Z

Allow painting or not painting (partial) matches in context lines when showing "grep -C" output in color. * rs/grep-color-words: grep: add color.grep.matchcontext and color.grep.matchselected

grep: add color.grep.matchcontext and color.grep.matchselected

2014-10-28T17:33:50Z

The config option color.grep.match can be used to specify the highlighting color for matching strings. Add the options matchContext and matchSelected to allow different colors to be specified for matching strings in the context vs. in selected lines. This is similar to the ms and mc specifiers in GNU grep's environment variable GREP_COLORS. Tests are from Zoltan Klinger's earlier attempt to solve the same issue in a different way. Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

color_parse: do not mention variable name in error message

2014-10-14T18:01:21Z

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 Signed-off-by: Junio C Hamano

Merge branch 'as/grep-fullname-config'

2014-06-03T19:06:39Z

Add a configuration variable to force --full-name to be default for "git grep". This may cause regressions on scripted users that do not expect this new behaviour. * as/grep-fullname-config: grep: add grep.fullName config variable

grep: add grep.fullName config variable

2014-03-20T19:38:00Z

This configuration variable sets the default for the --full-name option. Signed-off-by: Andreas Schwab Signed-off-by: Junio C Hamano

Merge branch 'rs/grep-h-c'

2014-03-18T20:51:20Z

"git grep" learns to handle combination of "-h (no header)" and "-c (counts)". * rs/grep-h-c: grep: support -h (no header) with --count t7810: add missing variables to tests in loop

grep: support -h (no header) with --count

2014-03-11T22:05:28Z

Suppress printing the header (filename) with -h even if in -c/--count mode. GNU grep and OpenBSD's grep do the same. Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

Use hashcpy() when copying object names

2014-03-06T22:03:12Z

We invented hashcpy() to keep the abstraction of "object name" behind it. Use it instead of calling memcpy() with hard-coded 20-byte length when moving object names between pieces of memory. Leave ppc/sha1.c as-is, because the function is about the SHA-1 hash algorithm whose output is and will always be 20 bytes. Helped-by: Michael Haggerty Helped-by: Duy Nguyen Signed-off-by: Sun He Signed-off-by: Junio C Hamano