Re: [RFC 1/2] grep: only add delimiter if there isn't one already

On Thu, Jan 19, 2017 at 10:39:02AM -0800, Junio C Hamano wrote:

Stefan Hajnoczi [off-list ref] writes:

quoted

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