BUG: "--work-tree blah" does not imply "--git-dir blah/.git" or fix misleading error message

Today someone asked me if there was a way to run git against a directory other than the current directory. I looked at the output of --help and ran this:

$ git --work-tree blah status

I got the following output:

fatal: Not a git repository (or any parent up to mount parent /home) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

I mistakenly thought the error message meant that blah was not a git repository. What it meant was that there was no .git in the current directory or any parent directory up to /home.

This command worked as expected:

$ git --work-tree blah --git-dir blah/.git status

The documentation is somewhat fuzzy about what constitutes a git repository. The gittutorial describes the git repository as .git when talking about "git init" while the Git User's Manual describes the git repository as the working tree and the special top-level directory named .git when talking about "git clone".

It's clear (to me at least) that --work-tree should be used to identify the root of the working tree when not inside the working tree. I expected that the git directory would be automatically set to .git in the root of the working tree, as that would match the documentation. Instead, the current directory and its parents were checked -- which could provide dangerously misleading information to the user.

I think that one of two things should be done: either the --git-dir default should be changed when the --work-tree option is set, or the error message cited above should be changed to explicitly identify the directory being tested as a potential git repository. I personally believe the first option is superior because it fulfills the expectations of average users (folks who read git's documentation instead of its source code) while permitting flexibility to those who wish to refer to the current directory or some other directory for their --git-dir value. If the current behavior is somehow not a bug but instead a critical and significant feature which if changed would cause more harm than good, please consider the second option.

Jack. -- mathuin at gmail dot com