Re: Bug: git-upload-pack will return successfully even when it can't read all references

On Mon, Sep 07, 2015 at 02:11:15PM +0200, Ævar Arnfjörð Bjarmason wrote: > 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. > > [...] > > I wanted to check if this was a

Re: Bug: git-upload-pack will return successfully even when it can't read all references

On Tue, Sep 8, 2015 at 8:53 AM, Jeff King wrote: > On Mon, Sep 07, 2015 at 02:11:15PM +0200, Ævar Arnfjörð Bjarmason wrote: > >> 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

Re: Bug: git-upload-pack will return successfully even when it can't read all references

On Tue, Sep 08, 2015 at 02:16:03PM +0200, Ævar Arnfjörð Bjarmason wrote: > I wonder if --upload-pack="GIT_REF_PARANOIA=1 git-upload-pack" should > be the default when running fetch if you have --prune enabled. There's > a particularly bad edge case now where if you have permission errors > on the

Bug: git-upload-pack will return successfully even when it can't read all references

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