Hello, On Fri, Sep 4, 2015 at 2:54 PM, Jeff King <peff@xxxxxxxx> wrote: > On Fri, Sep 04, 2015 at 12:52:45PM +0200, Giuseppe Bilotta wrote: > >> Notice two things: the messages refer to the worktree updir of the >> CLIENT machine, and even though it's _completely not obvious_ due to >> the missing 'remote:' lines, the messages actually come from the >> SERVER. The lack of indicator lines _alone_ took me hours of debugging >> before I finally understood that they were coming from the other side > > Older versions of receive-pack would let unpack-objects output go > straight to stderr, but that changed in a22e6f8 (receive-pack: send > pack-processing stderr over sideband, 2012-09-21), which is in git > v1.7.12.3. What version of git is running on the remote server? Sorry, I forgot to mention this in my origina email, I should have. The remote is quite ancient: git version 1.7.0.4 >> I still couldn't do much on the SERVER to debug due to a variety of >> reasons, but I finally had a suspicion: it was almost as if the SERVER >> was getting the GIT_DIR information from the CLIENT. And why the heck >> would _that_ be the case? >> >> I then remembered that the server was actually configured to AcceptEnv >> GIT_* in sshd_config, for reasons related to git identity preservation >> despite single login account (please don't ask). Turning the AcceptEnv >> to a stricter GIT_AUTHOR* and GIT_COMMITTER* solved the issue. > > I couldn't reproduce this problem, either during a local push, or across > an ssh session (where the client has "SendEnv GIT_*" and the server has > "AcceptEnv GIT_*"). [snip] > On the receiving side, git-receive-pack takes an argument for the repo > path, and calls enter_repo. That should result in calling set_git_dir(), > which overwrites $GIT_DIR in the environment. AFAICT, it has always done > so. So I'm not sure how GIT_DIR would leak through, even on an older > version of git. Hm, aside from the ancient version of git, the other side also has gitolite2 running (can you tell it's an ancient installation that needs upgrading?). However,I've done a quick test by creating an empty bare git repository outside of gitolite2, and I'm still getting the same error, so I would exclude gitolite2 interference. In fact, your testing approach gave me the idea to test by prepending env 1>&2 to the receive pack and this way I noticed that the variable being set was GIT_WORK_TREE. In fact, using --receive-pack 'export -n GIT_WORK_TREE ; git-receive-pack' fixes the problem for me. So, I've at least been able to circumscribe the problem to: server git 1.7.0.4, client git 2.5, GIT_WORK_TREE being sent over the ssh connection. I'll see if I can find some time to do some proper bisecting next week. -- Giuseppe "Oblomov" Bilotta -- 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