Re: [PATCH] Fix git_setup_directory_gently when GIT_DIR is set

Johannes Schindelin [off-list ref] writes:

quoted

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.