Re: [BUG] `git gc` or `git pack-refs` wipes all notes for `git notes` command

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 6, 2023, 12:40 UTC
Message-ID: <xmqqilhjsuo9.fsf@gitster.g>
In-Reply-To: <Y7fikyZV1ky2modr@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 16 quoted lines

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

Show 13 quoted lines

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