Re: [RFC/PATCH 4/4] Disallow working directory commands in a bare repository.

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.