<feed xmlns='http://www.w3.org/2005/Atom'>
<title>git/grep.c, branch v2.9.2</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/git/git.git/
</subtitle>
<id>https://git.shady.money/git/atom?h=v2.9.2</id>
<link rel='self' href='https://git.shady.money/git/atom?h=v2.9.2'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/git/'/>
<updated>2016-06-27T16:56:24Z</updated>
<entry>
<title>Merge branch 'rs/xdiff-hunk-with-func-line' into maint</title>
<updated>2016-06-27T16:56:24Z</updated>
<author>
<name>Junio C Hamano</name>
<email>gitster@pobox.com</email>
</author>
<published>2016-06-27T16:56:24Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/git/commit/?id=fda65fadb6e98b5b8ea8058bbeaa29d983f335cb'/>
<id>urn:sha1:fda65fadb6e98b5b8ea8058bbeaa29d983f335cb</id>
<content type='text'>
"git show -W" (extend hunks to cover the entire function, delimited
by lines that match the "funcname" pattern) used to show the entire
file when a change added an entire function at the end of the file,
which has been fixed.

* rs/xdiff-hunk-with-func-line:
  xdiff: fix merging of appended hunk with -W
  grep: -W: don't extend context to trailing empty lines
  t7810: add test for grep -W and trailing empty context lines
  xdiff: don't trim common tail with -W
  xdiff: -W: don't include common trailing empty lines in context
  xdiff: ignore empty lines before added functions with -W
  xdiff: handle appended chunks better with -W
  xdiff: factor out match_func_rec()
  t4051: rewrite, add more tests
</content>
</entry>
<entry>
<title>grep: -W: don't extend context to trailing empty lines</title>
<updated>2016-05-31T20:08:56Z</updated>
<author>
<name>René Scharfe</name>
<email>l.s.r@web.de</email>
</author>
<published>2016-05-28T15:06:19Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/git/commit/?id=4aa2c4753d152aef810eaf3f3f4fa1df7035d9b0'/>
<id>urn:sha1:4aa2c4753d152aef810eaf3f3f4fa1df7035d9b0</id>
<content type='text'>
Empty lines between functions are shown by grep -W, as it considers them
to be part of the function preceding them.  They are not interesting in
most languages.  The previous patches stopped showing them for diff -W.

Stop showing empty lines trailing a function with grep -W.  Grep scans
the lines of a buffer from top to bottom and prints matching lines
immediately.  Thus we need to peek ahead in order to determine if an
empty line is part of a function body and worth showing or not.

Remember how far ahead we peeked in order to avoid having to do so
repeatedly when handling multiple consecutive empty lines.

Signed-off-by: Rene Scharfe &lt;l.s.r@web.de&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
</entry>
<entry>
<title>grep.c: use error_errno()</title>
<updated>2016-05-09T19:29:08Z</updated>
<author>
<name>Nguyễn Thái Ngọc Duy</name>
<email>pclouds@gmail.com</email>
</author>
<published>2016-05-08T09:47:47Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/git/commit/?id=7645d8f119997320c33423d95670824f05657bbb'/>
<id>urn:sha1:7645d8f119997320c33423d95670824f05657bbb</id>
<content type='text'>
While at there, improve the error message a bit (what operation failed?)

Signed-off-by: Nguyễn Thái Ngọc Duy &lt;pclouds@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
</entry>
<entry>
<title>use xmallocz to avoid size arithmetic</title>
<updated>2016-02-22T22:51:09Z</updated>
<author>
<name>Jeff King</name>
<email>peff@peff.net</email>
</author>
<published>2016-02-22T22:44:28Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/git/commit/?id=3733e6946465d4a3a1d89026a5ec911d3af339ab'/>
<id>urn:sha1:3733e6946465d4a3a1d89026a5ec911d3af339ab</id>
<content type='text'>
We frequently allocate strings as xmalloc(len + 1), where
the extra 1 is for the NUL terminator. This can be done more
simply with xmallocz, which also checks for integer
overflow.

There's no case where switching xmalloc(n+1) to xmallocz(n)
is wrong; the result is the same length, and malloc made no
guarantees about what was in the buffer anyway. But in some
cases, we can stop manually placing NUL at the end of the
allocated buffer. But that's only safe if it's clear that
the contents will always fill the buffer.

In each case where this patch does so, I manually examined
the control flow, and I tried to err on the side of caution.

Signed-off-by: Jeff King &lt;peff@peff.net&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
</entry>
<entry>
<title>color: add color_set helper for copying raw colors</title>
<updated>2015-10-05T18:08:05Z</updated>
<author>
<name>Jeff King</name>
<email>peff@peff.net</email>
</author>
<published>2015-09-24T21:08:21Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/git/commit/?id=7ce4fb948c6d196a376a37840cb80ae95b5897ec'/>
<id>urn:sha1:7ce4fb948c6d196a376a37840cb80ae95b5897ec</id>
<content type='text'>
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 &lt;peff@peff.net&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
</entry>
<entry>
<title>grep: use xsnprintf to format failure message</title>
<updated>2015-09-25T17:18:18Z</updated>
<author>
<name>Jeff King</name>
<email>peff@peff.net</email>
</author>
<published>2015-09-24T21:06:51Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/git/commit/?id=19bdd3e7e160a0b000c15d8bf6d33f4149e3f911'/>
<id>urn:sha1:19bdd3e7e160a0b000c15d8bf6d33f4149e3f911</id>
<content type='text'>
This looks at first glance like the sprintf can overflow our
buffer, but it's actually fine; the p-&gt;origin string is
something constant and small, like "command line" or "-e
option".

Signed-off-by: Jeff King &lt;peff@peff.net&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'jk/blame-commit-label'</title>
<updated>2015-02-11T21:39:50Z</updated>
<author>
<name>Junio C Hamano</name>
<email>gitster@pobox.com</email>
</author>
<published>2015-02-11T21:39:50Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/git/commit/?id=092c4be7f5d691809913eb83a2360f035c67ab06'/>
<id>urn:sha1:092c4be7f5d691809913eb83a2360f035c67ab06</id>
<content type='text'>
"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
</content>
</entry>
<entry>
<title>use xstrdup_or_null to replace ternary conditionals</title>
<updated>2015-01-13T18:05:48Z</updated>
<author>
<name>Jeff King</name>
<email>peff@peff.net</email>
</author>
<published>2015-01-13T01:59:09Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/git/commit/?id=8c53f0719b04e0b6328c2e175e3c5d2dc8a0c282'/>
<id>urn:sha1:8c53f0719b04e0b6328c2e175e3c5d2dc8a0c282</id>
<content type='text'>
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-&gt;foo) : NULL").

Signed-off-by: Jeff King &lt;peff@peff.net&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'rs/grep-color-words'</title>
<updated>2014-10-31T18:49:47Z</updated>
<author>
<name>Junio C Hamano</name>
<email>gitster@pobox.com</email>
</author>
<published>2014-10-31T18:49:37Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/git/commit/?id=bf1f639ea2cb54f5dee2f1fe3435d0072ede9abb'/>
<id>urn:sha1:bf1f639ea2cb54f5dee2f1fe3435d0072ede9abb</id>
<content type='text'>
Allow painting or not painting (partial) matches in context lines
when showing "grep -C&lt;num&gt;" output in color.

* rs/grep-color-words:
  grep: add color.grep.matchcontext and color.grep.matchselected
</content>
</entry>
<entry>
<title>grep: add color.grep.matchcontext and color.grep.matchselected</title>
<updated>2014-10-28T17:33:50Z</updated>
<author>
<name>René Scharfe</name>
<email>l.s.r@web.de</email>
</author>
<published>2014-10-27T18:23:05Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/git/commit/?id=79a77109d3d0d364910ff7fa8c605c554dc4c3e0'/>
<id>urn:sha1:79a77109d3d0d364910ff7fa8c605c554dc4c3e0</id>
<content type='text'>
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 &lt;l.s.r@web.de&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
</entry>
</feed>
