On Thu, Jan 19, 2017 at 11:59:59AM -0500, Jeff King wrote:
> On Thu, Jan 19, 2017 at 03:03:45PM +0000, Stefan Hajnoczi wrote:
> 
> > git-grep(1)'s output is not consistent with git-rev-parse(1) revision syntax.
> > 
> > This means you cannot take "rev:path/to/file.c: foo();" output from git-grep(1)
> > and expect "git show rev:path/to/file.c" to work.  See the individual patches
> > for examples of command-lines that produce invalid output.
> 
> I think this is a good goal.
> 
> I couldn't immediately think of any cases where your patches would
> misbehave, but my initial thought was that the "/" versus ":"
> distinction is about whether the initial object is a tree or a commit.
> 
> You do still have to special case the root tree (so "v2.9.3:" does not
> get any delimiter). I think "ends in a colon" is actually a reasonable
> way of determining that.
> 
> > This series is an incomplete attempt at solving the issue.  I'm not familiar
> > enough with the git codebase to propose a better solution.  Perhaps someone is
> > interested in a proper fix?
> 
> Are there cases you know that aren't covered by your patches?

From Patch 2/2:

  This patch does not cope with @{1979-02-26 18:30:00} syntax and treats
  it as a path because it contains colons.

If we use obj->type instead of re-parsing the name then that problem is
solved.