corrupted repo and "git push --mirror"

Sitaram Chamarty· Oct 18, 2010, 04:08 UTC · lore

This is probably a stupid question, but in the spirit of extreme paranoia *and* because it's kinda hard to "try it and see", I'm going to risk the ridicule :)

Gitolite has mirroring support now, basically using "git push --mirror". The question I was asked, and I couldn't *confidently* answer, was: what happens if the source repo suffers some corruption for some reason? Does the corruption propagate?

I suspect not, but I'd appreciate corraboration and if anyone can sat what actually will happen that'd be great.

Secondary question: what happens if the receiving repo is corrupt?

Thanks!

-- 
Sitaram

Ilari Liusvaara· Oct 18, 2010, 09:06 UTC · re: Sitaram Chamarty · lore

Re: corrupted repo and "git push --mirror"

On Mon, Oct 18, 2010 at 09:38:03AM +0530, Sitaram Chamarty wrote:

Show 8 quoted lines

> This is probably a stupid question, but in the spirit of extreme
> paranoia *and* because it's kinda hard to "try it and see", I'm going
> to risk the ridicule :)
> 
> Gitolite has mirroring support now, basically using "git push
> --mirror".  The question I was asked, and I couldn't *confidently*
> answer, was: what happens if the source repo suffers some corruption
> for some reason?  Does the corruption propagate?

I think the sending behaves like normal repack. The packfile object CRCs must match (assuming they are available, i.e. v2 index!). Loose objects might be down to zlib adler checksum.

However, some errors in pack generation process could cause logically inconsistent pack to be sent. Against that, one would need to enable receive-side fsck on receive (this is how the infamous jgit push bug corrupted repositories).

Transport errors are caught by underlying MACs or packfile SHA-1.

> Secondary question: what happens if the receiving repo is corrupt?

The push might fail or it might not. And not even receive-side fsck necressary catches the corruption (one would need full fsck for that).

-Ilari