Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > Junio C Hamano wrote: >> Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > >>> In git versions including the patch 2cd83d10bb6b (setup: suppress >>> implicit "." work-tree for bare repos, 2013-03-08, currently in "next" >>> but not "master"), you can set GIT_IMPLICIT_WORK_TREE=0 to avoid this >>> behavior. >> >> WAT? > > Is that false? > > If I understand the history correctly, the ability to set the GIT_DIR > envvar was meant to allow a person to keep their .git directory outside > the worktree. So you can do: > > git init my-favorite-repo > cd my-favorite-repo > ...work as usual... > > # cleaning time! > mv .git ~/my-favorite-repo-metadata.git > GIT_DIR=$HOME/my-favorite-repo-metadata.git; export GIT_DIR > ... work as usual... ... as usual except that you have to be at the top. And that is why GIT_WORK_TREE was invented, so that you can anchor where the top of the tree is with that variable and then chdir around into its subdirectories. Also later we added core.worktree so that $GIT_DIR/config can say where its associated working tree is. > This is of course unsafe because it ties your usage to a specific > version of git. And the variable is not advertised in the > documentation. We decided not to advitise it exactly because we do not intend to guarantee that will be the way that variable will work. It is an implementation detail of that "alias" stuff in the topic it addresses. The documented way is to point at the tip with GIT_WORK_TREE. -- 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