Need to set GIT_WORK_TREE when setting GIT_DIR !?

Hi all,

I want to set GIT_DIR to another path than <project_dir>/.git. Unfortunately, git add or git status failed with the following error:

fatal: This operation must be run in a work tree

Unless I also set GIT_WORK_TREE, git status|add|stash|clean|... always fail.

git or git-config man pages does not state anything like this. Did I miss something ?

#test-case :

export GIT_DIR=$PWD/.gita && git init echo "file a" >> a.txt && git add a.txt #fail git status #fail

export GIT_WORK_TREE=$PWD git status #pass git add a.txt && git commit -m'file a' #pass

unset GIT_WORK_TREE git status #fail, it does not look like some bug related to a newly created, empty repository

Note: that using --git-dir instead of GIT_DIR give the same errors.

-- Fred

Frédéric Heitzmann  <frederic.heitzmann@gmail.com> writes:

Yes, to the question on the Subject line.  But you can also say 

    [core] worktree = /path/to/the/work/tree

in $GIT_DIR/config. Make sure your $GIT_DIR/config does *NOT* say that the repository is a bare repository.

Yes, that is the intended behaviour; the command line option and the environment variable should give you the same consistent effect).

Le 10/03/2012 00:06, Junio C Hamano a écrit :

Thanks for clarification. However man git-config says :

"If --git-dir or GIT_DIR is specified but none of --work-tree, GIT_WORK_TREE and core.worktree is specified, the current working directory is regarded as the top level of your working tree."

Some more context on my precise problem : I have a project, with source files managed with git. I also use some Makefiles that I would like to manage with git _in a separate repository_

$ GIT_DIR=<project_path>/.git git add some_file.c ... $ GIT_DIR=<project_path>/.git_mk git add Makefile ...

Setting worktree in each GIT_DIR/config will fix that but I can't figure out why current git implementation actually needs this.

-- Fred

2012/3/10 Frédéric Heitzmann <frederic.heitzmann@gmail.com>:

Historical reason: before separate worktree feature was introduced, git assumed worktree was at $GIT_DIR's parent directory. Old scripts may rely on that behavior.

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

Isn't the rule that the current directory becomes the root of the working tree if you did not have GIT_WORK_TREE?

In any case, the way I read Frédéric is that the other repository's files will be accessed only from the root of the working tree, so as long as the GIT_DIR/config says it is not a bare repository, it should be OK.

Hi,

Frédéric Heitzmann wrote:

This is where the recipe goes wrong. It creates a bare repository. Using vi or "git config" to edit its configuration to set the "[core] bare" setting to false would change that.

The git-config(1) manpage says:

	By default a repository that ends in "/.git" is assumed to be
	not bare (bare = false), while all other repositories are
	assumed to be bare (bare = true).

and the logic in builtin/init-db.c seems to agree.

Maybe there is a better place to document this. Improvements welcome.

Thanks, Jonathan

Hi all,

My initial mistake was that I unintenionnaly created a bare repo (which is really not what I want to do). If I change that - GIt_DIR=.gita git init --no-bare - everything runs fine.

Lessons learned :

1/ the kind of repo - bare or not bare - that git init creates depends on GIT_DIR. This _is_ documented - I should have read more carefully - but it is surprising for someone not aware of the history of GIT_DIR, GIT_WORK_TREE, and so on. Don't know if it 's worth changing this semantic though. I let more experienced git hackers decide on this.

2/ Calling a git command that needs a working tree (add, status, commit, ...) in a bare repo should probably trigger a more explicit message. Using the current directory if GIT_WORK_TREE is not set would actually hide a potential configuration problem.

Thanks for your help, -- Fred