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

"Shawn O. Pearce" [off-list ref] writes:

Agreed.  But as you point out...
 

quoted

If we could outlaw $GIT_DIR/index in a bare repository, then
...
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.

This, and this,...

quoted

...
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.
...
Why not just tell these users to setup the working directories with
local .git directories and not use GIT_DIR?

suggest that we might want to bite the bullet and declare that
these things are not supported anymore in v1.5.0.

So far, especially after fixing the i18n issue in response to
qgit problem report, I do not think we have any serious backward
incompatibility that the users cannot opt out of that we need to
mention in v1.5.0 announcement.  Even not the incompatibilities
the 'old news' section talks about are.

I think an index file in a bare repository is not what the user
wanted to have because it was useful, but is left there because
it does not hurt.  So in that sense, I do not think we need to
ask users' permission to do this change, as long as we make sure
we give them enough advance warning.

I do not offhand think of a valid workflow that relies on
setting GIT_DIR in the environment and being able to run
working-tree commands, that cannot be worked around if we declar
that GIT_DIR is for our internal use (and no, naming the
directory other people call .git to .svn does not count as a
valid workflow), but I think this may be a bit more serious
change than the index file one.

Comments?