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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 30, 2011, 19:21 UTC
Message-ID: <7vaa7dquva.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAEUMa-cA8qPjJuPBREE1RqhgwmcZG7x1MjBYkxa3i+ZSAnMPOA@mail.gmail.com>

John Twilley <mathuin@gmail.com> writes:

Show 9 quoted lines

> 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)

Yeah, that is a "this a use case that we didn't even intend to support, and as a consequence we do a random thing" bug.

Originally, when GIT_DIR is set (from the environment, and then later we added "git --git-dir=..." as another way to do so), Git always used the current directory as the top of the working tree. There was no mechanism for the user to say "No, I am not at the top level, but I am in a subdirectory of the working tree. The top of working tree is there". That was the use case GIT_WORK_TREE (from the environment, and then later we added "git --work-tree=..." as another way to do so) was introduced for.

So in that sense, it is an unsupported mode of operation and it is not surprising at all if Git did any random and meaningless things if you used GIT_WORK_TREE without specifying GIT_DIR at all. In the same sense, strictly speaking, setting GIT_WORK_TREE to somewhere that is not a parent directory of the current directory (even if you set GIT_DIR) is also an unsupported mode of operation.

When GIT_DIR is not set, I think we still run the normal GIT_DIR discovery starting from the current working directory, and when we do not find one, we would error out, as you saw. I am sympathetic that your particular case might have resulted in a more pleasant user experience if the GIT_DIR discovery started from the directory specified by GIT_WORK_TREE (i.e. the subdirectory "blah/.git"), but I do not think this is likely to change, as I suspect that people and scripts are relying on the current behaviour to be able to do something like this:

    cd /pub/scm/git/git.git ;# this is a bare repository
    mkdir /var/tmp/git
    git --work-tree=/var/tmp/git checkout

to have a temporary checkout, and changing the GIT_DIR discovery logic will break them, i.e. they now have to do:

    cd /pub/scm/git/git.git ;# this is a bare repository
    mkdir /var/tmp/git
    git --work-tree=/var/tmp/git --git-dir=$(pwd) checkout

or something. Instead, what you wanted to do is already supported by:

    (cd blah && git status)

so nothing is lost.

We could reword this:

> fatal: Not a git repository (or any parent up to mount parent /home)

to "fatal: /home/bar/baz (or any parent ...) is not a git repository" to mention the current directory /home/bar/baz, but I am having a hard time convincing myself that such a change is particularly good, because almost always you know where you are (many people have it in their shell prompt). Such a change makes the message longer to fit on a line without adding much value.