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