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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 26.03.2012 20:01, schrieb Junio C Hamano:
René Scharfe<rene.scharfe@xxxxxxxxxxxxxx>  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é
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]