Re: [PATCH 0/4] grep: add more information to hunk separators

["René Scharfe" <rene.scharfe@lsrfire.ath.cx>]

Am 26.03.2012 20:01, schrieb Junio C Hamano:
> René Scharfe<rene.scharfe@lsrfire.ath.cx>  writes:
>
>> Looking at the above, I thought: We have unified diffs between two
>> files, we have combined diffs between more than two, what about
>> showing grep results as one-sided unified diffs?  ("What's the sound
>> of one hand clapping?" :-)
>>
>> 	--- a/git.c
>> 	@ -570,3 @ int main(int argc, const char **argv)
>> 	-		printf("usage: %s\n\n", git_usage_string);
>> 	:		list_common_cmds_help();
>> 	-		printf("\n%s\n", git_more_info_string);
>>
>> Pro: Generalization of an established format for showing interesting
>> parts of a file.  Less duplication of meta-information.  Markers that
>> tell us the kind of the shown lines are kept ("-" for context, ":" for
>> matches).  Machine parsable.
>>
>> Con: Why the "a/" prefix?  One-sided diffs, srsly?
>
> Cute, and I tend to agree that this is probably easier to read if you are
> used to reading unified diffs.
>
> Wouldn't it make more sense to replace your '-/:' with ' /=', so that at
> least ' ' SP retains the meaning of "this is shown merely to give you
> context, it is not a proper part of what you are looking for"?

Ah, good idea, the space makes for a less cluttered output.  For 
completeness sake, I have to mention that the current grep output uses 
'-/:/=', however, for context/match/function line ("especially 
interesting context").  Even function lines that happen to fall within 
the --context are marked with an equal sign.  That's not the case for 
unified diffs; they simply get shown as normal context.

> The reasoning behind '=' is that it is not either -/+ as we are not really
> comparing anything with anything.

Mapping the '-/:/=' of grep to ' /:/=' or ' /:/ ' might be easier to 
understand.  However, seeing a line starting with a colon or an equal 
sign feels both strange, because they are normally used as binary 
operators.  Normal grep output shows a filename or a line number before 
the separator, so it doesn't invoke that strange feeling.

Perhaps mapping to ' /!/ ' is better instead, similar to context diffs?

> It may also make sense to replace the
> per-file header line with "=== git.c" to be consistent.

A context diffs would have '*** git.c', but they are ugly IMHO, overall.

What we also could do: Produce a valid unified diff that would remove 
the matching lines if we were to apply it (or the --reverse, i.e. + 
instead of -).  Then we wouldn't need to invent a special format, but 
the output would be a bit more verbose due to the added +++ lines.

I guess it's time to implement these options in order to try them out 
against real code.  Won't have time to do so before the second half of 
the week, however.

René