On Tue, Jan 31, 2017 at 12:27 AM, Jeff King <peff@xxxxxxxx> wrote: > On Sat, Jan 28, 2017 at 05:29:32PM -0700, Bob Proulx wrote: > >> However the problem driving me crazy is that this only fails this way >> on one machine. Unfortunately failing on the machine I need to use. >> If I try this same setup on any other machine I try then there is no >> failure and it works okay. Therefore I conclude that in the failing >> case it is trying to write a shallow_XXXXXX file in the repository but >> in all of the passing cases it does not. I browsed through the >> git-daemon source but couldn't deduce the flow yet. >> >> Does anyone know why one system would try to create shallow_XXXXXX >> files in the repository while another one would not? > > It depends on the git version on the server. The interesting code is in > upload-pack.c, which is spawned by git-daemon to serve a fetch or clone > request. > > See commit b790e0f67 (upload-pack: send shallow info over stdin to > pack-objects, 2014-03-11), which lays out the history. Since that commit > (in git v2.0.0), there should be no tmpfile needed. It must be it. There's nowhere else that upload-pack can create shallow_XXXXXX. (receive-pack and fetch-pack can). >> Of course git-daemon running as nobody can't create a temporary file >> shallow_XXXXXX in the /srv/git/test-project.git because it has no >> permissions by design. But why does this work on other systems and >> not work on my target system? >> >> git --version # from today's git clone build >> git version 2.11.0.485.g4e59582 > > This shouldn't be happening with git v2.11. Are you sure that the "git > daemon" invocation is running that same version? I notice you set up a > restricted PATH. Is it possible that /usr/local/bin or /usr/bin has an > older version of git? One easy way to verify is clone or fetch again with GIT_TRACE_PACKET=1 since we send the server's version as a capability since 1.8.0 -- Duy