Re: [PATCH 04/10] Migrate git-clone to use git-rev-parse --parseopt

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 6, 2007, 19:39 UTC
Message-ID: <7vmytrgo4q.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.LFD.0.9999.0711061355330.21255@xanadu.home>

Nicolas Pitre <nico@cam.org> writes:

Show 15 quoted lines

> On Sun, 4 Nov 2007, Pierre Habouzit wrote:
>
>> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
>> ---
>>  git-clone.sh |  102 +++++++++++++++++++++++++++++++++-------------------------
>>  1 files changed, 58 insertions(+), 44 deletions(-)
>
> Well, this patch was merged in "next" and broke git-clone rather badly.
>
> Just try something as fundamental as this:
>
> 	$ git clone git://git.kernel.org/pub/scm/git/git.git
> 	fatal: Not a git repository
>
> Don't we have test cases covering this really basic operation?

We do, but RUN_SETUP will happily go up to find the .git/ next to t/ directory that is the parent of trash/ directory, in which the tests run, without reporting errors. As parseopt does not depend on anything in git, this will not do any harm other than falsely succeeding the test that should not pass.

We could probably introduce an environment variable, GIT_CEILING, that tells the setup_git_directory_gentry() never go up beyond that point, and set it to the t/trash directory while running the test.

Something like that may have other uses in practice. Often people wonder what would happen if there is /.git repository and they would want to make sure they would not accidentally add to the repository controlled by /.git when they have bunch of other repositories /some/where/.git in which they usually work.