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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



John Twilley <mathuin@xxxxxxxxx> writes:

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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]