staging.git; --depth=1 doesn't seem to work with "smart http"

[Paul Sokolovsky]

Following up to meeting with Rob:

$ git clone http://staging.git.linaro.org/git/toolchain/gcc.git
- works as expected

$ git clone --depth=1 http://staging.git.linaro.org/git/toolchain/gcc.git
Cloning into 'gcc'...
fatal: The remote end hung up unexpectedly
fatal: protocol error: bad pack header

[Milo Casagrande (milo)]

So, I took a look at this problem, and found out what's going on.
I'm not sure why it started to act like that: the only idea I have is that with recent version of git something changed in the way git commands are run, since previously a clone operation with --depth=1 was working.

From Apache log, when trying to clone a repository, we can find this:

fatal: Unable to create temporary file '/srv/repositories/lava/lava-server.git/shallow_zjbO0B': Permission denied
fatal: The remote end hung up unexpectedly

Looking at the process table and their command line, this is the command that is run by git:

git --shallow-file shallow_NPYjEM pack-objects --revs --thin --stdout --progress --delta-base-offset

The repository directories under /srv/repositories on the server are set with the following access: rwxr-----, and are owned by git:git.

The process that runs git during a clone operation via smart HTTP is run under www-data, and www-data is part of the git group on the server, but does not have write access to the directories.

Just changing the permission on the directory solved the problem, and I was able to perform a clone operation.

[Milo Casagrande (milo)]

Write access in this case is needed by "git --shallow-file shallow_XXXX", since it needs to temporary write that file. Once the process is done the file does not exists anymore.

[Milo Casagrande (milo)]

I fixed the default UMASK for gitolite so that it now is 0007, resulting in rwxrwx--- for directories, and rw-rw---- for files. I also updated all the existing dirs and files.

[Paul Sokolovsky (pfalcon)]

Great investigation and fix. Confirming it works for me too.

One suggestion I have - if you make any changes, please try to encode them in ansible in linaro-git-tools repo ;-). (Not sure if that applies to this case though.)