Mark Lodato [off-list ref] 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.
In other words, I am not yet convinced this belongs to "git grep" proper.
Am 26.03.2012 07:14, schrieb Junio C Hamano:
Mark Lodato[off-list ref] writes:
quoted
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é
On Mon, Mar 26, 2012 at 07:14, Junio C Hamano [off-list ref] wrote:
Mark Lodato [off-list ref] writes:
quoted
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.
FYI, I once posted a git-gui grep prototype:
[off-list ref]
I have since added it to git-gui, see bw/master~2 'git-gui: add grep
tab' in http://repo.or.cz/w/git-gui/bertw.git.
Bert
In other words, I am not yet convinced this belongs to "git grep" proper.