"git apply" refused to apply the patch, but I applied it by hand, and it
seems to work fine.  Thanks.

On Sun, Jul 30, 2017 at 8:30 AM <npostavs@users.sourceforge.net> wrote:

> tags 27873 + patch
> quit
>
> Eric Hanchrow <eric.hanchrow@gmail.com> writes:
>
> > This displayed a *grep* buffer that looked something like I expected,
> > but:
> >
> > * instead of there being exactly one line with some underlining
> > (indicating a "hit"), there were a bunch: the one I expected, as well
> > as a few before it like this:
> >
> > grep: git-repositories: Is a directory
> > grep: guix: Is a directory
> > grep: homedir: Is a directory
> > grep: homework: Is a directory
> > grep: iTunesDSM: Is a directory
> > grep: jessie64: Is a directory
> > grep: local: Is a directory
> > grep: log: Is a directory
> > grep: mygo: Is a directory
> > grep: node_modules: Is a directory
> > grep: perl5: Is a directory
> > phonetic-alphabet.txt1:Stolen from
> http://www.fourmilab.ch/documents/phoneticalphabet/
> > grep: pprof: Is a directory
> >
> > You can't tell from what I've pasted above, but the 9 "Is a directory"
> > lines before the actual hit were red and underlined, just like the
> > match was.
> >
> > * Hitting C-x `, instead of visiting the file with the hit, put a
> > nine-line-high prompt in the minibuffer, as if it was asking me which
> > directory to find the file in a directory with a really weird name.
> > (You can see some evedince of this in the "Recent messages" stuff below).
>
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27840 is a similar report
> from a few days ago.
>
> It's not a duplicate though, this bug is because I thought using --null
> would make it possible to get filenames containing newlines
> unambiguously, but I was wrong.  Here's a patch, also covers a couple of
> minor issues that came up later in Bug#6843.
>
>