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.
signature.asc
Description: PGP signature
