Re: [PATCH] Fix initialization of a bare repository

Johannes Schindelin [off-list ref] writes:

	Maybe this is not enough, though.  Maybe we need to check if the 
	GIT_DIR=. too, since 7efeb8f0 would set the work tree to ".", too.

	But maybe this would merit a separate fix in set_work_tree(), like

		if (!strcmp(getenv(GIT_DIR_ENVIRONMENT), ".")) {
			inside_work_tree = 0;
			return NULL;
		}

	Hmm?

I do not know.  If you treat "." differently from a pathname
that is the same as what $(pwd) would give you, you will confuse
even more users.

Currently we have:

 - char *git_work_tree_cfg: the location of the work tree when
   $GIT_WORK_TREE nor --work-tree option is in use.  Contrary to
   the name of the variable, it does not necessarily come from
   core.worktree.  This comes from core.worktree if set,
   otherwise derived from the location of the repository
   (i.e. unless $GIT_DIR is set, above "/.git" of the found
   repository, otherwise ".").

 - char *work_tree: the location of the work tree, which comes
   from $GIT_WORK_TREE (or --work-tree option) if set, otherwise
   git_work_tree_cfg above.

 - int inside_work_tree: is $(cwd) inside of the work tree (if
   we have one)?

 - int is_bare_repository_cfg: are we treating this repository
   as bare?  Contrary to the name of the variable, it does not
   necessarily come from core.bare (get_git_work_tree()
   overwrites the value found in core.bare to false in if we
   have a work_tree).

 - int is_bare_repository(): are we treating this repository
   as bare?  This is the function the callers usually use.

I think tying the presense of work_tree and repository bareness
as is_bare_repository() does is almost always right for the
normal callers.  One valid use of GIT_WORK_TREE is to put a work
tree to a repository otherwise declared as a bare one.

But obviously init-db is rather a special case with a chicken
and egg problem.  What it wants to know is not if we are
currently treating the repository as a bare one, but if we would
want to mark its core.bare with "this should be normally treated
as bare".  Your patch treats this special case as such without
affecting the normal codepath, which I think is a sane thing to
do.

Thanks for a quick fix.