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

Junio C Hamano [off-list ref] wrote:

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.

Agreed.  But as you point out...
 

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.

I almost coded the require_not_bare() to look for $GIT_DIR/index
but didn't for the reasons you point out above.  It is too bad that
we didn't enforce the existance of the index file better in the past.

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 

What happens with $GIT_DIR/index in this case?  Or $GIT_DIR/HEAD?
Its insane because both need to be affiliated with the working
directory, yet there's only the one set.  Sure the user could also
arrange for $GIT_INDEX_FILE to be set based on the working directory,
but what about $GIT_DIR/HEAD?  There is no equivilant.

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.

I wouldn't be hurt, but I don't call Porcelain-ish unless I'm
entering commands directly on the command line, and I never set
GIT_DIR except in scripts, and even then its very rare and is more
to point at a bare repository than one with a working directory.
I suspect that probably isn't true for everyone.

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.

I'm not sure what value that environment variable offers here.

Users who set GIT_DIR but don't today set GIT_WORKTREE_TOP are
broken by this change because its not set and we assume its bare.
So they need to also set this environment variable.  But that
is probably going to be annoying for those users as I doubt they
are setting GIT_DIR on a per-directory basis.

Why not just tell these users to setup the working directories with
local .git directories and not use GIT_DIR?

-- 
Shawn.