On Fri, Feb 5, 2010 at 7:24 AM, René Scharfe <rene.scharfe@xxxxxxxxxxxxxx> wrote: > OK, I have to admit defeat: I can't come up with a test script. But > the issue is reproducible: git grep in a bare repository fails when > run with a pager. > > $ mkdir /tmp/a > $ cd /tmp/a > $ git init > Initialized empty Git repository in /tmp/a/.git/ > $ echo a >a > $ git add a > $ git commit -m. > [master (root-commit) e11f955] . > 1 files changed, 1 insertions(+), 0 deletions(-) > create mode 100644 a > > $ git clone --bare . ../b > Initialized empty Git repository in /tmp/b/ > $ cd /tmp/b > > $ git grep a HEAD > fatal: This operation must be run in a work tree > $ git grep a HEAD | cat > HEAD:a:a > $ git --no-pager grep a HEAD > HEAD:a:a > > Reverting 7e622650 (grep: prepare to run outside of a work tree), or > rather just setting the flag RUN_SETUP for grep in git.c again, makes > the first git grep call succeed, too. > > As does the following patch, but I don't know why. The call chain is > quite deep. It seems that without the patch the static variable > git_dir in environment.c isn't updated when git finds out that it runs > in a bare repo -- but only if a pager is used. setup_pager() calls git_config(), which indirectly calls get_git_dir() and sets git_dir in stone. Changing GIT_DIR environment variable alone won't work, as you have seen. When RUN_SETUP is set, setup_git_directory() would be called before setup_pager() can kick in, so everything is properly set. > There are five more sites in git.c, path.c and setup.c where $GIT_DIR > is set directly with setenv(). I wonder if they should better call > set_git_dir() instead, too. Yes, they should. -- Duy -- 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