From: Sergio Callegari <scallegari@arces.unibo.it>
To: git@vger.kernel.org
Subject: Re: Problem with pack
Date: Sun, 27 Aug 2006 19:45:09 +0200 [thread overview]
Message-ID: <44F1DA25.3050403@arces.unibo.it> (raw)
>
> 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!
> 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?
> 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!
> 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
next reply other threads:[~2006-08-27 17:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-27 17:45 Sergio Callegari [this message]
2006-08-27 18:27 ` Problem with pack Linus Torvalds
2006-08-27 19:26 ` Nicolas Pitre
2006-08-27 21:55 ` Junio C Hamano
-- strict thread matches above, loose matches on Subject: below --
2006-08-26 18:53 Sergio Callegari
2006-08-26 19:24 ` Linus Torvalds
2006-08-26 18:49 Sergio Callegari
2006-08-25 12:31 Sergio Callegari
2006-08-26 18:20 ` Linus Torvalds
2006-08-25 10:07 Sergio Callegari
2006-08-25 10:20 ` Andreas Ericsson
2006-08-25 10:41 ` Jakub Narebski
2006-08-25 10:58 ` Junio C Hamano
2006-08-26 10:09 ` Junio C Hamano
2006-08-26 10:31 ` Junio C Hamano
2006-08-25 8:45 Sergio Callegari
2006-08-25 9:12 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44F1DA25.3050403@arces.unibo.it \
--to=scallegari@arces.unibo.it \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).