Re: Problem with pack

From: Sergio Callegari <scallegari@arces.unibo.it>
Date: Aug 27, 2006, 17:45 UTC
Message-ID: <44F1DA25.3050403@arces.unibo.it>

Show 7 quoted lines

>
> I do think that your synchronization using unison is _somehow_ part of the 
> reason why bad things happened, but I really can't see why it would cause 
> problems, and perhaps more importantly, git should have noticed them 
> earlier (and, in particular, failed the repack). So a git bug and/or 
> misfeature is involved somehow.
>

Glad if my broken pack can help finding out!

Show 9 quoted lines

> One thing that may have happened is that the use of unison somehow 
> corrupted an older pack (or you had a disk corruption), and that it was 
> missed because the corruption was in a delta of the old pack that was 
> silently re-used for the new one.
>
> That would explain how the SHA1 of the pack-file matches - the repack 
> would have re-computed the SHA1 properly, but since the source delta 
> itself was corrupt, the resulting new pack is corrupt.
>

There is something that I still do not understand... (sorry if I ask stupid questions)... Since packs have an sha signature too, if there was a data corruption (disk or transfer), shouldn't that have been detected at the repack? I.e. doesn't repack -d verify the available data before cancelling anything?

Show 5 quoted lines

> If you had used git itself to synchronize the two repositories, that 
> corruption of one repo would have been noticed when it transfers the data 
> over to the other side, which is one reason why the native git syncing 
> tools are so superior to doing a filesystem-level synchronization.
>

I think I learnt the lesson!

> With a filesystem-level sync (unison or anything else - rsync, cp -r, 
> etc), a problem introduced in one repository will be copied to another one 
> without any sanity checking.
>

Idem!

Show 6 quoted lines

> but in the meantime, when you find a place to put the corrupt pack/index 
> file, please include me and Junio at a minimum into the group of people 
> who you tell where to find it (and/or passwords to access it). I'll 
> happily keep your data private (I've done it before for others).
>
>

Sure... I have already sent an email to Junio to arrange this.

Thanks, Sergio