git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: John Twilley <mathuin@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: BUG: "--work-tree blah" does not imply "--git-dir blah/.git" or fix misleading error message
Date: Wed, 30 Nov 2011 11:21:29 -0800	[thread overview]
Message-ID: <7vaa7dquva.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CAEUMa-cA8qPjJuPBREE1RqhgwmcZG7x1MjBYkxa3i+ZSAnMPOA@mail.gmail.com> (John Twilley's message of "Wed, 30 Nov 2011 09:43:08 -0800")

John Twilley <mathuin@gmail.com> 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.

  parent reply	other threads:[~2011-11-30 19:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-30 17:43 BUG: "--work-tree blah" does not imply "--git-dir blah/.git" or fix misleading error message John Twilley
2011-11-30 18:22 ` Carlos Martín Nieto
2011-11-30 19:13   ` John Twilley
2011-12-01 14:30     ` Carlos Martín Nieto
2011-11-30 19:21 ` Junio C Hamano [this message]
2011-11-30 19:42   ` Carlos Martín Nieto
2011-11-30 20:45     ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vaa7dquva.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=mathuin@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).