Thread (1 message) 1 message, 1 author, 2025-10-02

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

From: Junio C Hamano <hidden>
Date: 2025-10-02 17:34:56

Patrick Steinhardt [off-list ref] writes:
quoted
...  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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help