"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > Agreed. But as you point out... > >> 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,... >> ... >> 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? - 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