Re: git-daemon shallow checkout fail
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Feb 2, 2017, 09:26 UTC
- Message-ID
- <CACsJy8DED9WRr_T6g43bxHUGQYVnfaTx15hqSGiiajvi0TxtuA@mail.gmail.com>
- In-Reply-To
- <20170130172730.x5guphyqf5fsfi7m@sigill.intra.peff.net>
On Tue, Jan 31, 2017 at 12:27 AM, Jeff King <peff@peff.net> wrote:
Show 20 quoted lines
> 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).
Show 12 quoted lines
>> 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