From: Junio C Hamano Date: Thu, 02 Oct 2025 17:34:53 GMT Subject: Re: [PATCH 1/1] files-backend: check symref name before update Message-ID: In-Reply-To: Patrick Steinhardt 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.