Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
