Re: git ls-files -o under .git/ prints all repository files

From: Junio C Hamano <junkio@cox.net>
Date: Jan 19, 2007, 19:03 UTC
Message-ID: <7vtzymhma2.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0701191600020.22628@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 9 quoted lines

> On Fri, 19 Jan 2007, Matthias Kestenholz wrote:
> ...
>> Why not check for /.git/ somewhere inside the current working directory 
>> (pwd) ? That's the way mercurial does it currently, and I think that is 
>> a sane thing to do _if_ you want to protect the user from his own 
>> stupidity.
>
> There are valid reasons why you might want to have a (possibly 
> temporary) repository _inside_ the GIT_DIR. You'd break these cases.

You are right that strstr(here, "/.git/") is not a good check.

If we really care about this problem (and I am not yet starting to think we might, but who knows, I reserve the right to change my mind every once in a while), we could make the commands that deal with working trees (that is, among the things under discussion in this thread, 'git-clean' always is, and 'git-ls-files' only when it is given options like '-o', '-k', '-m', '-i') when the cwd is GIT_DIR or a subdirectory of it.

If you did something like:

	mkdir /var/tmp/a
        cd /var/tmp/a
        git init-db
        cd .git
        GIT_DIR=.git git init-db
        git add .
	git ls-files
	echo junk >garbage
        git clean

the repository at /var/tmp/a/.git/.git ought to track HEAD, config and friends in /var/tmp/a/.git directory.

Not that I am saying I think the above is a sensible use case.