On Thu, Feb 09, 2017 at 12:20:34AM -0500, Jeff King wrote:
> On Wed, Feb 08, 2017 at 09:14:17PM -0800, Junio C Hamano wrote:
> > Jeff King writes:
> (I _do_ think Stefan's proposed direction is worth it simply because the
> result is easier to read, but I agree the whole thing can
On Fri, Jan 20, 2017 at 03:51:33PM -0800, Brandon Williams wrote:
> On 01/20, Junio C Hamano wrote:
> > Stefan Hajnoczi <stefa...@redhat.com> writes:
> >
> > > If the tree contains a sub-directory then git-grep(1) output contains a
> > > colo
On Fri, Jan 20, 2017 at 02:56:26PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > It's not ignored; just as with git-log, it's a pathspec to limit the
> > diff. E.g.:
> >
> > $ git show --name-status v2.9.3
> > ...
> > M Documentation/RelNotes/2.9.3.txt
> > M
On Fri, Jan 20, 2017 at 10:16:31AM -0800, Junio C Hamano wrote:
> Stefan Hajnoczi <stefa...@redhat.com> writes:
>
> > v2.9.3::Makefile may convey that the user originally provided v2.9.3:
> > but is that actually useful information?
>
> You are either asking a wro
the individual patches
for examples of command-lines that produce invalid output.
Stefan Hajnoczi (2):
grep: only add delimiter if there isn't one already
grep: use '/' delimiter for paths
builtin/grep.c | 8 +++-
t/t7810-grep.sh | 26 ++
2 files changed, 33 in
already ends with ':' or '/':
$ git grep malloc v2.9.3:
v2.9.3:t/test-lib.sh: setup_malloc_check () {
$ git show v2.9.3:t/test-lib.sh
(succeeds)
Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com>
---
builtin/grep.c | 6 +-
t/t7810-grep.sh | 21 +
2
attempts to use the correct delimiter:
$ git grep malloc v2.9.3:t
v2.9.3:t/test-lib.sh: setup_malloc_check () {
$ git show v2.9.3:t/test-lib.sh
(success)
Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com>
---
builtin/grep.c | 4 +++-
t/t7810-grep.sh | 5 +
2 files chan
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:
On Thu, Jan 19, 2017 at 10:29:34AM -0800, Brandon Williams wrote:
> On 01/19, Stefan Hajnoczi wrote:
> > If the tree contains a sub-directory then git-grep(1) output contains a
> > colon character instead of a path separator:
> >
> > $ git grep malloc v2.9.3:t
On Thu, Jan 19, 2017 at 10:54:02AM -0800, Junio C Hamano wrote:
> Stefan Hajnoczi <stefa...@redhat.com> writes:
>
> > If the tree contains a sub-directory then git-grep(1) output contains a
> > colon character instead of a path separator:
> >
> > $ git grep
On Thu, Jan 19, 2017 at 10:39:02AM -0800, Junio C Hamano wrote:
> Stefan Hajnoczi <stefa...@redhat.com> writes:
>
> > git-grep(1) output does not follow git's own syntax:
> >
> > $ git grep malloc v2.9.3:
> > v2.9.3::Makefile: COMPAT_CFLAGS += -Icomp
already ends with ':' or '/':
$ git grep malloc v2.9.3:
v2.9.3:Makefile: COMPAT_CFLAGS += -Icompat/nedmalloc
$ git show v2.9.3:Makefile
(succeeds)
Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com>
---
builtin/grep.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
attempts to use the correct delimiter:
$ git grep malloc v2.9.3:t
v2.9.3:t/test-lib.sh: setup_malloc_check () {
$ git show v2.9.3:t/test-lib.sh
(success)
This patch does not cope with @{1979-02-26 18:30:00} syntax and treats
it as a path because it contains colons.
Signed-off-by: Stefan
oduce invalid output.
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?
Stefan Hajnoczi (2):
grep: only add delimiter if there isn't one already
grep: use '/'
14 matches
Mail list logo