Re: [PATCH] Fix git_setup_directory_gently when GIT_DIR is set

[Junio C Hamano <junkio@cox.net>]

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

>> 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.