Agreed. I've had this `git grep`-based solution in my `~/.gitconfig` for a while now. It's a bit tidier, but not as featureful.

    [alias]
            grepgvim = "!f() { git grep -l \"$@\" | xargs gvim -p; }; f"

It seems "Tag" is a little fancier in that it lets you go to specific matching lines, for the specific match. Tag is a command-line equivalent to `git cola grep <pattern>`, where you can select the matches visually in a GUI (with keyboard shortcuts) and then launch $EDITOR (e.g. gvim) on the matching line.

To the Tag author, maybe users would find this tidier if `tag` let you edit matches directly by invoking e.g. `tag func -e 96` and tag will do the rest?

In such a scheme someone could even set the alias file to `/dev/null` and it'd allow both the current workflow and a new one that didn't rely on aliases.

    EDITOR="FOO"
    $EDITOR $FILE

Are there issues with this? I can't imagine a reason they'd need to export $EDITOR to the parent shell process.

It looks like the alias file is overwritten with each invocation.

The alias file is indeed overwritten on every invocation, but tag doesn't attempt to clean up stale aliases from previous invocations. I figured it wasn't really worth implementing this since, as far as I know, shells don't slow down from having "too many aliases".

tag is very cool, but please don't implement the shortcuts with shell aliases:

  ~/badcode$ echo "func" > badfile.go\;\ echo\ \"Gotcha\!\"
  ~/badcode$ ls
 badfile.go; echo "Gotcha!"
  ~/badcode$ tag func
 badfile.go; echo "Gotcha!"
 [1] 1:func
  ~/badcode$ e1
 Gotcha! +1

In case that's not clear, I was able to create a file with a name that contains potentially malicious shell commands that is now bound to an alias via tag.

Other ways to implement the shortcuts: create a flag or subcommand to look up an hit from the results file and jump to it (I can alias this command to suit my taste) or prompt me for input before returning to the command line.