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

From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Date: Jun 13, 2022, 21:45 UTC
Message-ID: <20220613214514.udtn35w7j6q2lrbh@meerkat.local>
In-Reply-To: <Yqet68Sll1cz+ySY@nand.local>

On Mon, Jun 13, 2022 at 05:36:43PM -0400, Taylor Blau wrote:

Show 7 quoted lines

> > 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