René Scharfe [off-list ref] 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"?
The reasoning behind '=' is that it is not either -/+ as we are not really
comparing anything with anything. It may also make sense to replace the
per-file header line with "=== git.c" to be consistent. I haven't formed
an opinion on the prefix yet; there might be a good reason to keep the
depth of the path each file appear in this "grep --unidiff-like" output
and "diff --patch" output, in which case "=== a/git.c" or "=== ./git.c"
might be give us more uniformity.
Am 26.03.2012 20:01, schrieb Junio C Hamano:
René Scharfe[off-list ref] writes:
quoted
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é