From: Patrick Steinhardt <ps@pks.im>
To: Joie Joie <soniqjjj@gmail.com>
Cc: Usman Akinyemi <usmanakinyemi202@gmail.com>,
christian.couder@gmail.com, git@vger.kernel.org,
Karthik Nayak <karthik.188@gmail.com>
Subject: Re: [Outreachy] fast-import: Use repo_for_each_pack() for duplicate checks
Date: Mon, 9 Nov 2026 08:35:37 +0100 [thread overview]
Message-ID: <avF3yR-PYA3_Ih3v@pks.im> (raw)
In-Reply-To: <CAH=d44co_ZFA8EJwAoFL4=88ZqWzO65_+GbHDZfjG8amR4cHBw@mail.gmail.com>
Hi Joie,
On Fri, Nov 06, 2026 at 06:44:49PM +0100, Joie Joie wrote:
> Hi Patrick,
>
> I was looking through `fast-import.c` and noticed that both
> `store_object()` and `stream_blob()` still loop through `files->dirs`
> to check whether an object is already in a pack.
>
> I saw that Git already has `repo_for_each_pack()`, which is used in
> places like `count-objects.c` and `pack-objects.c`.
>
> Would it be worth using that iterator in these two places instead? The
> idea would be to avoid accessing the files backend directly while
> keeping the current packed-object lookup and duplicate-handling
> behavior unchanged.
No. `repo_for_each_pack()` was introduced as a helper function to make
the migration towards pluggable object databases a bit easier. But it is
ultimately still flawed, as it assumes that the backend uses packfiles
in the first place. So the goal is rather to eventually get rid of this
macro altogether in favor of higher-level interfaces that can be
implemented by arbitrary backends.
For git-fast-import(1) this will be done by making use of transactions,
and Karthik has already started taking a look at it, so I've Cc'd him.
For other subsystems we'll need to investigate how to do it properly.
Thanks!
Patrick
next prev parent reply other threads:[~2026-11-09 7:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 17:44 [Outreachy] fast-import: Use repo_for_each_pack() for duplicate checks Joie Joie
2026-11-09 7:35 ` Patrick Steinhardt [this message]
2026-11-09 15:25 ` Karthik Nayak
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=avF3yR-PYA3_Ih3v@pks.im \
--to=ps@pks.im \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=karthik.188@gmail.com \
--cc=soniqjjj@gmail.com \
--cc=usmanakinyemi202@gmail.com \
/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