Re: What's cooking in git.git (topics)

From: Matthias Lederhofer <matled@gmx.net>
Date: Jun 28, 2007, 20:23 UTC
Message-ID: <20070628202321.GA13263@moooo.ath.cx>
In-Reply-To: <7vtzsurvo1.fsf@assigned-by-dhcp.pobox.com>

Junio C Hamano <gitster@pobox.com> wrote:

Show 17 quoted lines

> I think the behaviour for receive-pack and the environment the
> hooks run in have been pretty well defined.  You start in the
> repository (the directory $GIT_DIR), GIT_DIR is set and points
> at it.
> 
> The issue is that the introduction of WORK_TREE enviornment and
> core.worktree mechanism might want to update the semantics.  For
> example, some people seem to run checkout (or perhaps "merge")
> to update the associated working tree.  Can they find out where
> the root of the working tree is (because they would want to
> chdir to it before saying "git checkout"), given the current
> environment receive-pack sets up for them?
>
> Earlier we said that people who use only GIT_DIR without
> GIT_WORK_TREE nor core.worktree should get exactly the same
> semantics with or without the WORK_TREE topic, so the above may
> not be an issue.

When GIT_WORK_TREE/core.worktree are not set the only difference with the patch series should be that cwd may be used as working tree in more cases than before.

I think these are the ways git-receive-pack is executed (in normal
setups):
 * local pushes: git_connect() unsets GIT_WORK_TREE.
 * ssh: the user might set GIT_WORK_TREE in his shell
   configuration, .ssh/environments, .ssh/authorized_keys etc.
   git-receive-pack is then executed with GIT_WORK_TREE set.
 * git-daemon: git-daemon with --enable=receive-pack allows pushing
   and does not unset GIT_WORK_TREE, so a git-daemon started with
   GIT_WORK_TREE exported will also have it exported when receive-pack
   is executed.

I think it makes sense to unset GIT_WORK_TREE when receive-pack is started. In the first case GIT_WORK_TREE is unset already and in the latter two cases I don't think we really need to support that GIT_WORK_TREE stays exported in the hooks, it could rather happen accidentally.

When doing more stuff in receive-pack old hooks might stop working break.

For example receive-pack could set up GIT_WORK_TREE with a sane
default value if a working tree can be found, i.e.
    $ export GIT_WORK_TREE=$(dirname $(pwd))
if the working tree is in the parent directory
    $ export GIT_WORK_TREE=$(git config core.worktree)
if core.worktree is set and otherwise GIT_WORK_TREE is not exported.
This way hooks can just use GIT_WORK_TREE for the working tree if
they don't need anything special.