Re: [PATCH] Fix initialization of a bare repository

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 15, 2007, 19:09 UTC
Message-ID: <7vlkccr4wu.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <Pine.LNX.4.64.0708151821260.19496@wbgn129.biozentrum.uni-wuerzburg.de>

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

Show 11 quoted lines

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