I think the intent is good.

But execution has room for improvement, and it is not your
fault.  The shell script version of require_not_bare is as
fragile as is_bare_git_dir(), which I already do not like, and I
think if we are going to use is_bare_git_dir() more, I think we
would want to have something a bit more robust.

If we could outlaw $GIT_DIR/index in a bare repository, then
lack of $GIT_DIR/index combined with nonexistence of ref that
is pointed at by $GIT_DIR/HEAD could become a good indication
that the repository is bare ("the current branch unborn" check
is needed not to mistake a repository before the initial commit
as a bare one).

Alas, many public repositories you would see (e.g. check
kernel.org) have been primed with rsync of .git/ from
developer's working repository and have leftover index that is
otherwise unused.  Because of this heavy historical baggage, I
suspect that it is rather hard to convince people to allow us to
use this technique.

When you have $GIT_DIR in your environment, no working-tree
command is expected to work unless you are at the toplevel of
the working-tree.  In the past, people talked about their
workflows using more than one working trees that are associated
with a single $GIT_DIR and that is certainly supposed to work.
But I wonder how widely such a set-up is employed in practice.
If we outlawed working-tree commands when $GIT_DIR environment
exists, how much hurt are we talking about, I wonder.

Another thing to think about is if we are happy with the above
restriction that makes environment $GIT_DIR to imply you are
always working at the toplevel.  Maybe it could be a good idea
to kill this bird as well by introducing $GIT_WORKTREE_TOP
environment variable.  Presence of it obviously means we are not
in a bare repository, but at the same time it would allow us to
teach setup_git_directory_gentry() to cd up to that directory to
make the commands behave as expected.




-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html