Hello all, I'm going to tell a tale of the oddest bug I've ever come across in Git and aks for suggestions on how we can improve the user experience in a sensible way. I've been stymied for days trying to solve the following issue, which I came across every time I tried to push to a specific machine when using git 2.5 (I'm honestly not sure about which version introduced this, and I haven't runthe necessary bisection due to lack of time, sorry). Trying to push any changes with 2.5 resulted in this kind of failure: user@clientmachine:~/some/git/workdir $ git push Counting objects: 6, done. Delta compression using up to 8 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (6/6), 841 bytes | 0 bytes/s, done. Total 6 (delta 2), reused 0 (delta 0) fatal: Could not switch to '/home/user/some/git': No such file or directory error: unpack failed: unpack-objects abnormal exit fatal: Could not switch to '/home/user/some/git': No such file or directory To git@remote.machine:remote-repo ! [remote rejected] master -> master (n/a (unpacker error)) error: failed to push some refs to 'git@remote.machine:remote-repo' 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 (yes, I woud say that it's a bug), but after this I was even more perplexed: why the heck would the SERVER try to switch to the updir of the CLIENT worktree? 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. Now, a couple of questions: 1. since when have git internals started exporting GIT_* variables related to the git dir and worktree location? 2. is it worth making sure that these don't get propagated via ssh? Regarding 2., there are actually webpages around suggesting the AcceptEnv GIT_* trick, and these setups are _all_ going to break with the latest git, so this is something that might be worth looking into. -- 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