On Mon, Aug 26, 2013 at 12:49 PM, Phil Hord <phil.hord@xxxxxxxxx> wrote: > If so, then I would like to point out to you the convenience I > accidentally encountered using this tool. Perhaps you didn't realize > how helpful it was when you chose to use a colon there. My itch comes from a case where I am looking for references in some other branch and I want to narrow my search. $ git grep object origin/master origin/master:.gitignore:/git-count-objects origin/master:.gitignore:/git-fsck-objects origin/master:.gitignore:/git-hash-object <8600 lines more deleted> I find hits in the region that interests me and then I try to zoom in there. Conveniently, the path I want to search is right there on my screen. So I copy the part of the object reference I want to limit my search to, and I try again: $ git grep object origin/master:builtin/ Now, I find the file that has the code I wanted. But I want to do something fancier to it than grep, so this time I copy-and-paste the filename into my command line after typing 'git show': $ git show origin/master:builtin/pack-objects.c | vim - But this doesn't work if the delimiter used was a colon. $ git show origin/master:builtin:pack-objects.c | vim - I have to edit my copy-and-pasted text, which means I have think about it a bit, and it interrupts all the other things I was thinking about already. Eventually I might learn to do this edit automatically, except it is not needed most of the time. It is only needed when I provide a tree-path instead of a "branch <space> path". In the latter case, the full path is spelled out for me correctly. And in all other cases the filenames provided by git-grep are valid filenames or object names. -- 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