Am 26.03.2012 07:14, schrieb Junio C Hamano:
Mark Lodato<lodatom@xxxxxxxxx> writes:Originally, I had envisioned also moving the function name (`-p') to the hunk header, similar to the diff context line. For example: -- git.c:570 -- int main(int argc, char argv) printf("usage: %s\n\n", git_usage_string); list_common_cmds_help(); printf("\n%s\n", git_more_info_string); After implementing this feature, I was not happy with the result and subsequently removed it. To me, the output was too cluttered and the line number was ambigous. For example, in the above, it is not obvious to me that line 570 is the "printf" line and not the "int main" line. Still, if you would like to see the patch to implement this feature, please let me know.The worst part of all of the above is that the output becomes utterly ambiguous and the reader cannot tell if "-- git.c..." came because the file had such a line that begin with two dashes in it and grep found it, or it is your output format embellishment. It is obvious that these are not meant to be machine parseable, but if the goal is to make the output more useful to the humans, then it may be a better approach to come up with a front end that reads our machine readable output and shows output with its own embellishments. You could even make it an interactive front end.
Human readers can differentiate between contents and heading by color; separators are cyan by default.
A separate frontend would probably have to implement match highlighting again. That's not too hard, but a bit sad.
In other words, I am not yet convinced this belongs to "git grep" proper.
All in all, I'm not sure either. But I think the idea to deduplicate the meta-information and give found content more screen real estate is a good one in general.
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