On Thu, Jan 19, 2017 at 10:39:02AM -0800, Junio C Hamano wrote:
> Stefan Hajnoczi <stefanha@xxxxxxxxxx> writes:
>
> > git-grep(1) output does not follow git's own syntax:
> >
> > $ git grep malloc v2.9.3:
> > v2.9.3::Makefile: COMPAT_CFLAGS += -Icompat/nedmalloc
> > $ git show v2.9.3::Makefile
> > fatal: Path ':Makefile' does not exist in 'v2.9.3'
> >
> > This patch avoids emitting the unnecessary ':' delimiter if the name
> > already ends with ':' or '/':
> >
> > $ git grep malloc v2.9.3:
> > v2.9.3:Makefile: COMPAT_CFLAGS += -Icompat/nedmalloc
> > $ git show v2.9.3:Makefile
> > (succeeds)
>
> I am mildly negative on this one. I suspect that the above example
> is a made-up one and you might have a more compelling real-world use
> case in mind, but at least the above does not convince me.
Another trailing delimiter example:
$ git grep malloc v2.9.3:t/
v2.9.3:t/:test-lib.sh: setup_malloc_check () {
After Patch 1/2:
v2.9.3:t/test-lib.sh: setup_malloc_check () {
> The end-user explicitly gave the extra ':' because she wanted to
> feed the tree object, not a tag that leads to the tree, for some
> reason. I think the output should respect that and show how she
> spelled the starting point. IOW, it is not "':' added unnecessarily
> by Git". It is ':' added by the end-user for whatever reason.
v2.9.3::Makefile may convey that the user originally provided v2.9.3:
but is that actually useful information? I don't see what the user will
do with this information (and they should already know since they
provided the command-line).
v2.9.3:Makefile can be copy-pasted or extracted by scripts for further
git commands. That is useful.
Stefan
Attachment:
signature.asc
Description: PGP signature