All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: Karthik Nayak <karthik.188@gmail.com>,
	 Han Young <hanyang.tony@bytedance.com>,
	 git@vger.kernel.org,  Han Young <hanyoung@protonmail.com>,
	 Sigma <git@sigma-star.io>
Subject: Re: [PATCH 1/1] files-backend: check symref name before update
Date: Thu, 02 Oct 2025 10:34:53 -0700	[thread overview]
Message-ID: <xmqqseg1w6ki.fsf@gitster.g> (raw)
In-Reply-To: <aN6amIG2Sp3W500K@pks.im> (Patrick Steinhardt's message of "Thu, 2 Oct 2025 17:30:32 +0200")

Patrick Steinhardt <ps@pks.im> 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.


  reply	other threads:[~2025-10-02 17:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-01 15:08 [PATCH 0/1] files-backend: check symref name before update Han Young
2025-10-01 15:08 ` [PATCH 1/1] " Han Young
2025-10-01 19:22   ` Junio C Hamano
2025-10-02  9:54     ` Karthik Nayak
2025-10-02 11:47       ` Patrick Steinhardt
2025-10-02 13:36         ` Junio C Hamano
2025-10-02 15:30           ` Patrick Steinhardt
2025-10-02 17:34             ` Junio C Hamano [this message]
2025-10-05  8:19         ` shejialuo
2025-10-02  9:34 ` [PATCH 0/1] " Karthik Nayak
2025-10-02 14:45   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqseg1w6ki.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@sigma-star.io \
    --cc=git@vger.kernel.org \
    --cc=hanyang.tony@bytedance.com \
    --cc=hanyoung@protonmail.com \
    --cc=karthik.188@gmail.com \
    --cc=ps@pks.im \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.