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

From: Junio C Hamano <[email-masked]>
Date: Thu, 02 Oct 2025 10:34:53 -0700

Patrick Steinhardt <[email-masked]> writes:

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