All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Matheus Tavares <matheus.bernardino@usp.br>
Cc: gitster@pobox.com, asheiduk@gmail.com, git@vger.kernel.org,
	greg@hurrell.net, l.s.r@web.de
Subject: Re: [PATCH] grep: follow conventions for printing paths w/ unusual chars
Date: Sat, 18 Apr 2020 16:56:57 +0200 (CEST)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.2004181655300.46@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.2004181509350.46@tvgsbejvaqbjf.bet>

Hi Matheus,

On Sat, 18 Apr 2020, Johannes Schindelin wrote:

> On Fri, 17 Apr 2020, Matheus Tavares wrote:
>
> > grep does not follow the conventions used by other Git commands when
> > printing paths that contain unusual characters (as double-quotes or
> > newlines). Commands such as ls-files, commit, status and diff will:
> >
> > - Quote and escape unusual pathnames, by default.
> > - Print names verbatim and unquoted when "-z" is used.
> >
> > But grep *never* quotes/escapes absolute paths with unusual chars and
> > *always* quotes/escapes relative ones, even with "-z". Besides being
> > inconsistent in its own output, the deviation from other Git commands
> > can be confusing. So let's make it follow the two rules above and add
> > some tests for this new behavior. Note that, making grep quote/escape
> > all unusual paths by default, also make it fully compliant with the
> > core.quotePath configuration, which is currently ignored for absolute
> > paths.
> >
> > Reported-by: Greg Hurrell <greg@hurrell.net>
> > Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
> > ---
> >  Documentation/git-grep.txt |  6 +++--
> >  builtin/grep.c             | 46 ++++++++++++++++++++++++++++----------
> >  t/t7810-grep.sh            | 44 ++++++++++++++++++++++++++++++++++++
> >  3 files changed, 82 insertions(+), 14 deletions(-)
>
> Unfortunately, this causes eight test failures on Windows:
> https://dev.azure.com/gitgitgadget/git/_build/results?buildId=38023&view=ms.vss-test-web.build-test-results-tab
>
> Could you please have a look? I suspect that this has something to do with
> those new tests needing the `FUNNYNAMES` prereq.

I need this commit to fix it:
https://github.com/git-for-windows/git/commit/7ca815e1ab89d6ffdb1a17b3cbacdf22a508d33c

I'll paste it here, for your convenience:

-- snipsnap --
From 7ca815e1ab89d6ffdb1a17b3cbacdf22a508d33c Mon Sep 17 00:00:00 2001
From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sat, 18 Apr 2020 16:49:43 +0200
Subject: [PATCH] fixup??? grep: follow conventions for printing paths w/
 unusual chars

It is easy to be fooled by the Bash included in Git for Windows, which
leads you to believe that quotes are valid parts of file names.

On Windows, they are not. But Cygwin (which is the base of MSYS2, which
is the POSIX emulation layer used by that Bash) only _pretends_ that it
is a valid file name character. In reality, it will map the character
into the private Unicode page. Cygwin knows about this. The rest of
Windows applications (including Git for Windows), however, does not.

As a consequence, `>\"with\ quotes\"` will claim to succeed, but the
file on disk will have Unicode characters in place of those quotes that
literally no application but Cygwin ones can handle, and this leads to
those beautiful new tests to fail.

Let's just use the prereq we introduced to guard precisely against this
problem: `FUNNYNAMES`.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t7810-grep.sh | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index ab495dba28a7..991d5bd9c03f 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -72,8 +72,11 @@ test_expect_success setup '
 	# Still a no-op.
 	function dummy() {}
 	EOF
-	echo unusual >"\"unusual\" pathname" &&
-	echo unusual >"t/nested \"unusual\" pathname" &&
+	if test_have_prereq FUNNYNAMES
+	then
+		echo unusual >"\"unusual\" pathname" &&
+		echo unusual >"t/nested \"unusual\" pathname"
+	fi &&
 	git add . &&
 	test_tick &&
 	git commit -m initial
@@ -484,7 +487,7 @@ do
 		test_cmp expected actual
 	'

-	test_expect_success "grep $L should quote unusual pathnames" '
+	test_expect_success FUNNYNAMES "grep $L should quote unusual pathnames" '
 		cat >expected <<-EOF &&
 		${HC}"\"unusual\" pathname":unusual
 		${HC}"t/nested \"unusual\" pathname":unusual
@@ -493,7 +496,7 @@ do
 		test_cmp expected actual
 	'

-	test_expect_success "grep $L in subdir should quote unusual relative pathnames" '
+	test_expect_success FUNNYNAMES "grep $L in subdir should quote unusual relative pathnames" '
 		cat >expected <<-EOF &&
 		${HC}"nested \"unusual\" pathname":unusual
 		EOF
@@ -504,7 +507,7 @@ do
 		test_cmp expected actual
 	'

-	test_expect_success "grep -z $L with unusual pathnames" '
+	test_expect_success FUNNYNAMES "grep -z $L with unusual pathnames" '
 		cat >expected <<-EOF &&
 		${HC}"unusual" pathname:unusual
 		${HC}t/nested "unusual" pathname:unusual
@@ -514,7 +517,7 @@ do
 		test_cmp expected actual-replace-null
 	'

-	test_expect_success "grep -z $L in subdir with unusual relative pathnames" '
+	test_expect_success FUNNYNAMES "grep -z $L in subdir with unusual relative pathnames" '
 		cat >expected <<-EOF &&
 		${HC}nested "unusual" pathname:unusual
 		EOF
--
2.26.1.windows.1


  reply	other threads:[~2020-04-18 14:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-13 21:55 git-grep's "-z" option misbehaves in subdirectory Greg Hurrell
2020-04-13 23:33 ` Junio C Hamano
2020-04-14  7:42 ` Matheus Tavares
2020-04-16 18:59 ` git-grep's "-z" option misbehaves in subdirectory Matheus Tavares Bernardino
2020-04-16 20:07   ` Junio C Hamano
2020-04-17  6:04     ` [PATCH] grep: follow conventions for printing paths w/ unusual chars Matheus Tavares
2020-04-17  6:45       ` Junio C Hamano
2020-04-17 21:19         ` Matheus Tavares Bernardino
2020-04-17 21:35           ` Junio C Hamano
2020-04-18 13:13       ` Johannes Schindelin
2020-04-18 14:56         ` Johannes Schindelin [this message]
2020-04-19  6:27           ` Matheus Tavares Bernardino
2020-04-19  6:33       ` [PATCH v2] " Matheus Tavares

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.2004181655300.46@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=asheiduk@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=greg@hurrell.net \
    --cc=l.s.r@web.de \
    --cc=matheus.bernardino@usp.br \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.