Re: [PATCH 1/1] files-backend: check symref name before update

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 2, 2025, 17:34 UTC
Message-ID: <xmqqseg1w6ki.fsf@gitster.g>
In-Reply-To: <aN6amIG2Sp3W500K@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 12 quoted lines

>> ...  As "git refs verify" is a way to do the sanity check of
>> the ref part (presumably without incurring cost to sanity check
>> other aspect, like fsck does?  why is it a separate command in the
>> first place?), ...
>
> We have the same pattern in other command:
>
>     - git commit-graph verify
>     - git multi-pack-index verify
>     - git bundle verify
>
> So `git refs verify` is following the same direction.

Well, bundle falls into a searate category, though.

A bundle file is a thing on its own and wants to be independently verifiable. A packfile (.pack alone without .idx) is also a thing that may want to be independently verifiable. For that they need to be accessible by end-users in a form of some command.

But everything else, ...

> I think it's a nice pattern to have this encapsulated functionality so
> that it's easy to exercise certain subsystems in isolation. git-fsck(1)
> then becomes a thin wrapper around these commands and is the one that
> ties it all together, if desired.

... including refs, commit-graphs, multi-pack-index do not have life on their own outside the repository they originate in, so there is no reason to expose them as separate commands to end-users.

I do agree that having a separate entry point for exercising them and them alone would help debugging and development, but such an entry point does not have to be a separate binary. It could have been "git fsck --refs-only" instead, for example.