From: "Jonathan Nieder" <>
Philip Oakley wrote:

It was Dale that had the problem, I was just suggesting where he might want to look... ;-)

A bit more looking gave that the cd_to_toplevel () in
directly uses `git rev-parse --show-toplevel`, which simply returns
work_tree (static char *work_tree; in environment.c, with comment /*
This is set by setup_git_dir_gently() and/or git_default_config()
*/), apparently without a check for the GIT_WORK_TREE.

Getting closer. :)

The usual way to use GIT_WORK_TREE is along with GIT_DIR.

When re-checking the manual's git(1) env variable section the comment that implies this didn't read well "The value will not be used in combination...". The section probably needs that to be stated explicitly ("an exported GIT_WORK_TREE is ignored if GIT_DIR is not set").

  That takes
you into the setup_explicit_git_dir() codepath, which does respect
GIT_WORK_TREE as it should.  (setup_discovered_git_dir does, too.)

The strange behavior you ran into is that unlike, say, and, filter-branch does not set SUBDIRECTORY_OK, store the
prefix from 'git rev-parse --show-prefix', and then cd_to_toplevel at
the top of the script.  In other words, nobody bothered to make it
work from anywhere other than the toplevel of the worktree to begin
with, and nobody wanted it enough to fix it later.

I maybe wrong, but I thought that in Dale's case he was already at the same level as the GIT_WORK_TREE he had set, so may not have expected to need a cd_to_toplevel

Dale did propose a patch in as the error was from later in the setup script.

Hope that helps,

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to