From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 04 Jan 2016 19:30:48 GMT
Subject: Re: [PATCH v2 16/17] grep: read -f file with strbuf_getline_crlf()
Message-ID: <xmqqmvslnnvb.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.20.1601041321360.14434@virtualbox>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Having said that, `grep` operates on lines of text,

Correct.

> and CR is established as a non-text byte,

Correct but only if you are a pedant.

With this patch, you can no longer find "A<CR>" on a "line" that is
"A<CR><LF>", which is a regression on a system whose native line
ermination convention is to use a single LF at the end.

The thing is, users know "grep -e '<a non-text byte>' finds hits
with a line with the non-text byte, and telling them that they
shouldn't rely on the feature would not make the world a better
place.

This patch limits the damage by restricting the special casing of CR
only at the end of the line just before LF, so we can still find
"A<CR>B" on a "line" that has a non-text byte, e.g. "A<CR>B<CR><LF>"
or "A<CR>B<LF>".  It is just a <CR> at the end of the line (with or
without any other string before it) for which we see a regression,
and I suspect that it would be a small enough price to accept to
help those who would need to work with <CRLF> systems.