All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: "René Scharfe" <l.s.r@web.de>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Calvin Wan" <calvinwan@google.com>,
	"Carlo Marcelo Arenas Belón" <carenas@gmail.com>,
	"Elijah Newren" <newren@gmail.com>, "Jeff King" <peff@peff.net>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"Mathias Krause" <minipli@grsecurity.net>,
	"Taylor Blau" <me@ttaylorr.com>,
	git@vger.kernel.org
Subject: Re: [PATCH 1/1] git-grep: improve the --show-function behaviour
Date: Mon, 11 Sep 2023 23:54:16 +0200	[thread overview]
Message-ID: <20230911215416.GA15714@redhat.com> (raw)
In-Reply-To: <e214eb9c-7576-f8f5-ef1d-3828affd47d8@web.de>

Hi René,

Thanks for feedback. I am already sleeping but let me try to reply anyway,
even if I don't really understand you.

On 09/11, René Scharfe wrote:
>
> Am 11.09.23 um 14:12 schrieb Oleg Nesterov:
> > show_funcname_line() returns when "lno <= opt->last_shown" and this
> > is not right in that the ->last_shown line (which matched the pattern)
> > can also have the actual function name we need to report.
> >
> > Change this code to check "lno < opt->last_shown". While at it, move
> > this check up to avoid the unnecessary "find the previous bol" loop.
> >
> > Note that --lno can't underflow, lno==0 is not possible in this loop.
> >
> > Simple test-case:
> >
> > 	$ cat TEST.c
> > 	void func(void);
> >
> > 	void func1(xxx)
> > 	{
> > 		use1(xxx);
> > 	}
> >
> > 	void func2(xxx)
> > 	{
> > 		use2(xxx);
> > 	}
> >
> > 	$ git grep --untracked -pn xxx TEST.c
> >
> > before the patch:
> >
> > 	TEST.c=1=void func(void);
> > 	TEST.c:3:void func1(xxx)
> > 	TEST.c:5:       use1(xxx);
> > 	TEST.c:8:void func2(xxx)
> > 	TEST.c:10:      use2(xxx);
> >
> > after the patch:
> >
> > 	TEST.c=1=void func(void);
> > 	TEST.c:3:void func1(xxx)
> > 	TEST.c=3=void func1(xxx)
> > 	TEST.c:5:       use1(xxx);
> > 	TEST.c:8:void func2(xxx)
> > 	TEST.c=8=void func2(xxx)
> > 	TEST.c:10:      use2(xxx);
> >
> > which looks much better to me.
>
> Interesting idea to treat function lines as annotations of matches
> instead of as special context.

Sorry, I don't understand... Let me repeat I am not familiar with this
code and terminology. Could you spell please?

> Showing lines twice feels wasteful, but
> at least for -p it might be justifiable from that angle.

Just in case... say, "func1" is reported twice only when it is really
needed. From the "after the patch" output above:

	TEST.c:3:void func1(xxx)

this is what we already have without this patch

	TEST.c=3=void func1(xxx)

this is what we have with this patch because the next

	TEST.c:5:       use1(xxx);

line needs the proper funcname line, and without this patch it would be
"void func()" which has nothing to do with use1(xxx),

If I do, say,

	./git grep --untracked -pn func1 TEST.c

then (with or without this patch) the output is

	TEST.c=1=void func(void);
	TEST.c:3:void func1(xxx)

in this case there is no reason to report "=void func1(xxx)".


> Wouldn't you
> have to repeat function line 3 before the match in line 8, though?

Why?

> The reason for not repeating a matched function line was that it
> doesn't add much information under the assumption that it's easy to
> identify function lines visually.

But it is not. Lets look again at the "before the patch:" output above,

 	TEST.c=1=void func(void);
 	TEST.c:3:void func1(xxx)
 	TEST.c:5:       use1(xxx);
 	TEST.c:8:void func2(xxx)
 	TEST.c:10:      use2(xxx);

it looks as if every "xxx" match is inside the (unrelated) func().

OK, "visually" you can also notice the "void funcX(xxx)" declarations
and understand whats going on.

But a) I don't think this is always easy, and b) it is certainly not
easy when you use "git-grep -p" in scripts. Please see 0/1.

> The patch would need to update Documentation/git-grep.txt as well to
> reflect the changed output.

Hmm... From Documentation/git-grep.txt:

	-p::
	--show-function::
		Show the preceding line that contains the function name of
		the match, unless the matching line is a function name itself.
		...

this is still true after this patch. How do you think I should update this
section?

Oleg.


  reply	other threads:[~2023-09-12  1:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-11 12:11 [PATCH 0/1] git-grep: improve the --show-function behaviour Oleg Nesterov
2023-09-11 12:12 ` [PATCH 1/1] " Oleg Nesterov
2023-09-11 20:11   ` René Scharfe
2023-09-11 21:54     ` Oleg Nesterov [this message]
2023-09-11 22:34   ` Junio C Hamano
2023-09-11 23:17     ` Oleg Nesterov
2023-09-12 13:04       ` Oleg Nesterov
2023-09-12 13:51         ` Oleg Nesterov
2023-09-12 18:07           ` René Scharfe
2023-09-13  0:31             ` Junio C Hamano
2023-09-13  9:46               ` Oleg Nesterov
2023-09-14 19:34                 ` René Scharfe
2023-09-17 16:44                   ` Oleg Nesterov
2023-09-14 19:34               ` René Scharfe
2023-09-13 10:15             ` Oleg Nesterov

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=20230911215416.GA15714@redhat.com \
    --to=oleg@redhat.com \
    --cc=avarab@gmail.com \
    --cc=calvinwan@google.com \
    --cc=carenas@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=l.s.r@web.de \
    --cc=me@ttaylorr.com \
    --cc=minipli@grsecurity.net \
    --cc=newren@gmail.com \
    --cc=peff@peff.net \
    --cc=torvalds@linux-foundation.org \
    /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.