Re: [Bug] git pull doesn't recognize --work-tree parameter

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 13, 2011, 18:01 UTC
Message-ID: <7vbotk6aae.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20111013155923.GA13134@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 20 quoted lines

> Changing these scripts to use require_work_tree_exists is
> easy to verify. We immediately call cd_to_toplevel, anyway.
> Therefore no matter which function we use, the state
> afterwards is one of:
>
>   1. We have a work tree, and we are at the top level.
>
>   2. We don't have a work tree, and we have died.
>
> The only catch is that we must also make sure no code that
> ran before the cd_to_toplevel assumed that we were already
> in the working tree.
>
> In this case, we will only have included shell libraries and
> called set_reflog_action, neither of which care about the
> current working directory at all.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> This is the low-hanging, obviously correct fruit.

I am not absolutely sure about "obviously correct", given that you assume that cd_to_toplevel does what its name makes you think it does. I've been wondering if we want to do give a bit more sanity to "cd_to_toplevel" and "rev-parse --show-toplevel".

    $ pwd
    /srv/project/git/git.git
    $ (cd Documentation/howto && git rev-parse --show-toplevel); echo $?
    /srv/project/git/git.git
    0

So far so good, however:

    $ (cd .git/refs/heads && git rev-parse --show-toplevel); echo $?
    0

I do not think this is quite right.

We would probably want to add "rev-parse --show-work-tree", but we would need to audit the users of cd_to_toplevel before starting to use it. I wouldn't be surprised if there is a script that creates a temporary work tree in .git/some/where and runs the scripted Porcelains without setting GIT_WORK_TREE, relying on the historical behaviour of cd_to_toplevel that does not really go to the top level.