Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> While we're talking about potentially deprecating GIT_DIR for users, >> out of curiosity, what valid workflows would cause users to want to >> use GIT_INDEX_FILE and GIT_OBJECT_DIRECTORY? Seems like they would >> cause more confusion and support problems than anything else. > > Easy, guys. > > It is a valid -- indeed, useful -- thing to be able to script nice > helpers. For example, in one project I track tar balls. So, I wrote a > script which will unpack the tar ball in a directory, build a new index > from it, and commit the corresponding tree on top of the tracking branch. > This setup relies _heavily_ on being able to redirect GIT_INDEX_FILE and > GIT_DIR. I do agree INDEX_FILE and OBJECT_DIRECTORY are handy things for the user to muck around. What I am not sure about is GIT_DIR, in the sense that I suspect it is not such a pain to do without for such a script. > ... Now, if somebody starts git in a > bare repo, where "index" is present, it could die with a helpful message > like > > It seems that this is a bare git repository, but there is an index > file present, which contradicts that assumption. If the repository > is indeed bare, please remove the index file. That is probably worse. * there is no reason for non working-tree operations such as git-log to fail when you go to a bare repository (or for that matter .git in a repository with a working-tree). we should not have to error out nor remove the index we will not use. * if you did the above in response to a misguided 'git checkout' in a bare repository, the next error message the user will get will be 'huh? you are in a bare repository, bozo'. So I do not think the helpful message should even be necessary. - 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