From: Matthias Lederhofer <matled@gmx.net>
Date: Tue, 26 Jun 2007 13:35:48 GMT
Subject: Re: What's cooking in git.git (topics)
Message-ID: <20070626133548.GB11504@moooo.ath.cx>
In-Reply-To: <7v645cz7vm.fsf@assigned-by-dhcp.pobox.com>

Junio C Hamano <gitster@pobox.com> wrote:
> * ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits
>  + make git barf when an alias changes environment variables
>  + setup_git_directory: fix segfault if repository is found in cwd
>  + test GIT_WORK_TREE
>  + extend rev-parse test for --is-inside-work-tree
>  + Use new semantics of is_bare/inside_git_dir/inside_work_tree
>  + introduce GIT_WORK_TREE to specify the work tree
>  + test git rev-parse
>  + rev-parse: introduce --is-bare-repository
>  + rev-parse: document --is-inside-git-dir
> * ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200) 9 commits
>  + filter-branch: always export GIT_DIR if it is set
> 
> I've been resisting these due to the size of the series, but I
> think the definition of is-bare is a bit saner than what we have
> in 'master', and I think it is the right direction in the longer
> term.  HOWEVER, I am not sure about the implementation and
> corner cases, e.g. what should it do in receive-pack?  You
> cannot rely on user setting GIT_WORK_TREE environment -- rather,
> receive-pack is responsible for setting up a sane environment
> for other commands to work in.

Thanks.  I'll have a look at receive-pack this week.  Is there
anything in receive-pack yet which helps to use a working tree in the
hooks?  Or is this something for which the behaviour of git still has
to be defined?