We have a process to back up our Git repositories at work, this
started alerting because it wasn't getting the same refs as the
remote.
This turned out to be a pretty trivial filesystem error.
refs/heads/master wasn't readable by the backup process, but some
other stuff in refs/heads and objects/* was.
But I think it's a bug that if we ssh to the remote end, and
git-upload-pack can't read certain refs in refs/heads/ that we don't
return an error.
This simple shellscript reproduces the issue:
rm -rf /tmp/repo /tmp/repo-checkout
git init /tmp/repo
cd /tmp/repo
touch foo
git add foo
git commit -m"foo"
git checkout -b branch
git checkout master
git show-ref
chmod 000 .git/refs/heads/master
git show-ref
cd /tmp
git clone repo repo-checkout
echo "Status code of clone: $?"
cd repo-checkout
git show-ref
After running this you get:
$ (cd /tmp/repo-checkout && echo -n | strace
/tmp/avar/bin/git-upload-pack /tmp/repo 2>&1 | grep -e EACCES)
open("refs/heads/master", O_RDONLY) = -1 EACCES (Permission denied)
open("refs/heads/master", O_RDONLY) = -1 EACCES (Permission denied)
open("refs/heads/master", O_RDONLY) = -1 EACCES (Permission denied)
And "git fetch" will return 0.
We fail to call get refs/heads/master in head_ref_namespaced() called
by upload_pack(). I was going to see if I could patch it to return an
error, but that code seems very far removed from any error checking.
This isn't only an issue with git-upload-pack, e.g. show-ref itself
has the same issue:
$ chmod 600 .git/refs/heads/master
$ git show-ref; echo $?
e7255c8fcabc6e15f57cd984f9f117870052c1a0 refs/heads/branch
e7255c8fcabc6e15f57cd984f9f117870052c1a0 refs/heads/master
0
$ chmod 000 .git/refs/heads/master
$ git show-ref; echo $?
e7255c8fcabc6e15f57cd984f9f117870052c1a0 refs/heads/branch
0
I wanted to check if this was a regression and got as far back as
v1.4.3 with the same behavior before the commands wouldn't work
anymore due to changes in the git config parsing code.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
