Re: [PATCH/RFC 0/4] grep: support to match by line number

From: Junio C Hamano <gitster@pobox.com>
Date: May 2, 2011, 19:30 UTC
Message-ID: <7vmxj4lx2e.fsf@alter.siamese.dyndns.org>
In-Reply-To: <BANLkTi=jABd5+_R-5SjhR163WV=TF1wbmQ@mail.gmail.com>

Bert Wesarg <bert.wesarg@googlemail.com> writes:

Show 7 quoted lines

> A build run will probably produce many warnings or errors (think of
> -j) for many files, so you need to handle more than one file. After
> the build run, you get a list of files which have warnings/errors,
> selecting one of the files will give you the original messages
> including the grep -@ output, from there you can select which message
> you want to consider opening in the editor, so grep -@ helps you in
> your decision what to open in your editor.

Now I got you talking ;-).

Wouldn't that workflow suggest that each invocation of -@ must be strongly paired with each path? After all, your hello.c having an error at line 100 does not have much to do with which lines in your goodbye.c are buggy.

Which has larger implications by opening a big can of worms. Just a few examples:

 - Should "git grep -@1 -@3 foo bar" show line 1 of foo and line 3 of bar,
   or should both lines 1 and 3 from both files be shown?  Why would
   anybody want to see line 3 of foo or line 1 of bar in such a case?

 - Later part of command line arguments on standard git command set are
   pathspecs, not necessarily individual paths.  You could for example say
   "git grep -@1 -@3 directory/". What should happen?  Should the first
   line of the first file in directory and the third line of the second
   file in directory be shown?  What would happen to the remaining files
   in the directory/?  You could replace "directory/" with "'*.c'".

   Perhaps use of -@ need to tighten the command line parsing to make sure
   that the user specified exact number of concrete filenames, not globs
   nor leading path prefixes, and otherwise error out?

I like "this range from this file, that range from that file" as a concept. It has far wider application than just in the context of "grep", and I want to see us do it right from the beginning if we _were_ to design it. That is why I am poking this discussion to make sure I can solicit deep enough thinking from people in the design phase.