Re: Repository corruption if objects pushed in the middle of repack

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 13, 2022 at 05:36:43PM -0400, Taylor Blau wrote:
> > I'm not sure that's the case, because the object that is missing is the one
> > that didn't exist before the repack started. In the scenario you describe, the
> > pre-existing unreachable ancestor of it would be missing, not the newly
> > incoming object. Right?
> 
> Aren't we reporting that the newly pushed tree was broken _because_ it
> had some links to sub-trees that no longer existed?

Hmm... now I'm not sure, and I don't have the broken repo in front of me any
more. :(

Well, the upside of this happening on a routine basis is that I can make
a copy of it next time so I can be more helpful in troubleshooting this
situation. Let me sit on this and make some copies next time this happens
(even if it's super annoying that it happens to such a large repo), and then
perhaps I can give you a better answer.

It's just strange that we've been doing something similar like this to tens of
thousands of repositories (e.g. those on codeaurora.org), and it's the first
time that I see such consistent corruption manifest itself. If I were to go
with my gut instinct, I would blame the shallow checkout on the client, but I
don't have any good way of explaining why that would be the culprit either.

-K



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux