Junio C Hamano <gitster@xxxxxxxxx> 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? - 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
