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"?
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.
--
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