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.
Th
On Thu, Jan 19, 2017 at 03:03:45PM +, 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 indi
On 01/19, Jeff King wrote:
> On Thu, Jan 19, 2017 at 03:03:45PM +, 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 s
On Thu, Jan 19, 2017 at 11:59:59AM -0500, Jeff King wrote:
> On Thu, Jan 19, 2017 at 03:03:45PM +, 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
> > g
On Fri, Jan 20, 2017 at 02:18:32PM +, Stefan Hajnoczi wrote:
> > 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->typ
5 matches
Mail list logo
