Re: [PATCH 1/2] grep: accept relative paths outside current working directory

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 6, 2009, 22:58 UTC
Message-ID: <7v3a6zu1dk.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20090905123117.GA3099@darc.dnsalias.org>

Clemens Buchacher <drizzd@aon.at> writes:

Show 12 quoted lines

> On Sat, Sep 05, 2009 at 12:58:50AM -0700, Junio C Hamano wrote:
>> >> If "git add -u ../.." (I mean "the grand parent directory", not "an
>> >> unnamed subdirectory") did not work 
>
> In git.git:
>
> $ cd t
> $ git grep addremove -- ../
> fatal: git grep: cannot generate relative filenames containing '..'
>
> So here's a fix for that. And a configurable solution for add and grep's
> scope as a follow-up. I did not look at any other commands yet.

Thanks. This was oa breakage I pointed out in an earlier message in this discussion, and it is worth fixing.

Your patch is queued in 'pu', but it seems to break the exit status in a strange way with my limited test.

Here is a non-broken behaviour without the "look in uplevel":

: git.git/cb/maint-1.6.3-grep-relative-up; ./git grep adddelete . : git.git/cb/maint-1.6.3-grep-relative-up; ./git grep adddelete .; echo $? 1 : git.git/cb/maint-1.6.3-grep-relative-up; ./git grep adddelete . >/dev/null; echo $? 1

Now we go down, and grep from an uplevel:

: git.git/cb/maint-1.6.3-grep-relative-up; cd t : t/cb/maint-1.6.3-grep-relative-up; ../git grep adddelete .. : t/cb/maint-1.6.3-grep-relative-up; ../git grep adddelete .. ; echo $? 1 : t/cb/maint-1.6.3-grep-relative-up; ../git grep adddelete .. >/dev/null; echo $? 0

The command should not give different exit status depending on the destination of standard output stream.