From: Junio C Hamano Date: Mon, 26 Mar 2012 18:01:21 GMT Subject: Re: [PATCH 0/4] grep: add more information to hunk separators Message-ID: <7vobrjp7gu.fsf@alter.siamese.dyndns.org> In-Reply-To: <4F709664.1060206@lsrfire.ath.cx> René Scharfe 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.