Re: [PATCH] Fix git_setup_directory_gently when GIT_DIR is set

From: Junio C Hamano <junkio@cox.net>
Date: Jun 5, 2006, 23:43 UTC
Message-ID: <7vfyij2mo8.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0606060117180.25685@wbgn013.biozentrum.uni-wuerzburg.de>

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

Show 12 quoted lines

>> Hmph.  Would it be a bug in clone that does not create GIT_DIR
>> then?
>
> I don't think so. The whole point in calling git-init-db is to create 
> that. GIT_DIR is set so that the otherwise nice work-in-a-subdirectory 
> does not kick in. Imagine for example:
>
> 	git-clone ./. victim
>
> (taken straight out of t5400). If GIT_DIR was not set, git-init-db (which 
> reads repositoryformat from the config if that exists, right?) would find 
> .git/ in git/t/trash, and _not_ create git/t/trash/victim/.git/.

I know clone currently relies on init-db to create the directory if it does not exist (I wrote the code after all).

I am questioning if that was a wise thing to do. In the case of clone, we _know_ where we want the directory to be, so creating the directory upfront before calling init-db feels like the right thing to do. In all the case other than this "clone calls init-db" I can think of, if we have GIT_DIR set and it is set to a non-existent location, it would be a bug in the code/script and I think it is saner to error out in such a case.