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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> wrote:
> 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.
-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux