git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: shejialuo <shejialuo@gmail.com>
To: git@vger.kernel.org
Cc: Patrick Steinhardt <ps@pks.im>,
	Karthik Nayak <karthik.188@gmail.com>,
	Michael Haggerty <mhagger@alum.mit.edu>,
	Junio C Hamano <gitster@pobox.com>
Subject: [RFC] Implement consistency check for packed refs
Date: Mon, 16 Dec 2024 21:58:13 +0800	[thread overview]
Message-ID: <Z2Ax9dtx4XE5xjgw@ArchLinux> (raw)

Hi all,

At current, I have already implemented the consistency check for files
backend. My next step is to implement the consistency check for packed
refs. And during these days, I have learned the source code of the
"refs/packed-backend.c".

The current "git-fsck(1)" implicitly checks the packed refs by calling
the method `refs/packed-backend.c::packed_refs_lock` which alls
`get_snapshot` and `create_snapshot`.

In the `create_snapshot` function, it will check some consistency of the
"packed-refs" file, if anything is wrong, the program will die.
"git-fsck(1)" relies on this to check the basic format correctness for
"packed-refs" file. It's not suitable to just call "packed_refs_lock"
in the code, we should not die the program.

Based on above, I have some ideas to implement the functionality. But
before I implement the actual code, I want to share my ideas to the
mailing list to get some feedback.

There are two ways we could add consistency check for packed refs.

1. We simply read the raw file "packed-refs" file, check each line. Of
course, we should also need to check whether the content is sorted.
2. We may reuse the data structure "struct snapshot" to do this. And we
call "packed_refs_lock" without calling the "creating_snapshot" instead,
we should just check. The reason why we do this is that we could reuse
some functions defined in the "packed-backend.c" instead of repeating
some logics. However, this way would be more complicated and require
more effort.

However, one thing I am not sure is that should we lock the raw file
when checking? From my perspective, we should lock the file because we
are checking the consistency of it. If other processes are processing
the "packed-refs", we may encounter inconsistency and things would be
strange.

Thanks,
Jialuo

             reply	other threads:[~2024-12-16 13:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-16 13:58 shejialuo [this message]
2024-12-16 14:49 ` [RFC] Implement consistency check for packed refs Patrick Steinhardt
2024-12-17 11:44   ` shejialuo

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=Z2Ax9dtx4XE5xjgw@ArchLinux \
    --to=shejialuo@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=karthik.188@gmail.com \
    --cc=mhagger@alum.mit.edu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).