Jeff King <peff@xxxxxxxx> writes: > On Thu, Jan 05, 2023 at 06:59:36PM +0200, Andrew Hlynskyi wrote: > >> > Can you share the .git directory of a repository that exhibits this >> > behavior? It's possible there's a bug or something in the packed-refs >> > code, though I find it pretty unlikely, as it's fairly well exercised in >> > normal use. >> >> The above excerpts completely describe the issue and there is no more >> special in the repo. > > Thanks for digging. Your explanation makes sense. > ... > I don't think we have any fsck checks that the packed-refs file is in > sorted order. It might be reasonable to have them. Likewise, when > pack-refs rewrites the file, it should be able to cheaply double-check > that the input is sorted by comparing each entry against its previous. True. I would not mind a patch to make us do so in the code path where we rewrite the file and add "sorted" trait to the file. refs/packed-backend.c::sort_snapshot() seems to be already equipped to do this? >> I understand that the `.git/packed-refs` file is for machines and not >> for humans but sometimes >> it's the fastest way to make several simple corrections in it manually. > > Yes, I have certainly done this myself. There are is a header line at > the top of the file, though, which tells what is guaranteed: > > $ head -1 .git/packed-refs > # pack-refs with: peeled fully-peeled sorted > > if you are going to muck with the file, deleting that line should be > sufficient; the reading code will fall back to the older routines which > don't assume it's sorted. Thanks, both. So we can conclude that this discussion thread has an incorrect Subject: and the symptom was caused by human error?
