From: Justin Tobler <jltobler@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Patrick Steinhardt <ps@pks.im>, git@vger.kernel.org
Subject: Re: [PATCH 1/4] odb: store ODB source in `struct odb_transaction`
Date: Thu, 29 Jan 2026 14:12:05 -0600 [thread overview]
Message-ID: <aXu4nttn-SWcMmLL@denethor> (raw)
In-Reply-To: <xmqqcy2sb4qr.fsf@gitster.g>
On 26/01/29 11:25AM, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> > This makes me wonder whether we should first refactor the `tmp_objdir`
> > subsystem to receive a source instead of a repository as input.
> > Otherwise we "pretend" that the transaction is on the source level, but
> > we ultimately still end up creating the temporary directory in the
> > repository's object directory unconditionally.
> >
> > It wouldn't really change anything right now as we only ever write
> > objects via the primary object source anyway, so the end result would be
> > the same. But it just feels like a good first step to me to fix this
> > conceptual inconsistency, and it shouldn't be too involved either as
> > `tmp_objdir_create()` only has three callsites.
>
> I agree with your "not really change anything right now" comment,
> but a new odb source that will be invented in the future may not
> even be file based, and a generic-sounding tmp_objdir_create() that
> creates a temporary directory on the filesystem may not even be an
> appropriate abstraction.
Yup, the tmp-objdir system is really only useful in the context of file
based ODB sources. I figure future ODB sources will have to have a
different mechanism to temporarly store objects.
Interestingly, it looks like there are only three users of odb-tmpdir:
remerge-diffs, git-recieve-pack, and ODB transactions. All of these
use-cases seems like a reasonble fit to create an ODB transaction
instead of managing the tmpdir directly. In the case of remerge-diffs
the transaction would need to always be aborted. If this is done, then a
tmpdir could become an internal detail of the ODB transaction for the
files backend.
> If we have two or more odb sources both are filesystem based, on the
> other hand, I do not think it is particulary bad if these two odb
> sources belonging to the same repository took a temporary directory
> out of that repository. As long as one temporary object directory
> taken by one odb source is not used to commit the transaction into
> the other odb source, it would be fine, no?
I believe that we only support having a single tmpdir per Git process
via `the_tmp_objdir` global anyway. So maybe on second thought
configuring per source doesn't make much sense especially if only the
"files" ODB source would make use of it. If we do go down the route of
merging the tmpdir with the "files" ODB transaction implementation, we
could probably just pass the concrete "files" ODB source to it instead.
-Justin
next prev parent reply other threads:[~2026-01-29 20:12 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-28 23:45 [PATCH 0/4] odb: support ODB source specific transaction handling Justin Tobler
2026-01-28 23:45 ` [PATCH 1/4] odb: store ODB source in `struct odb_transaction` Justin Tobler
2026-01-29 11:24 ` Patrick Steinhardt
2026-01-29 19:25 ` Junio C Hamano
2026-01-29 20:12 ` Justin Tobler [this message]
2026-01-29 20:28 ` Junio C Hamano
2026-01-29 21:54 ` Justin Tobler
2026-01-29 19:30 ` Justin Tobler
2026-01-28 23:45 ` [PATCH 2/4] object-file: rename transaction functions Justin Tobler
2026-01-28 23:45 ` [PATCH 3/4] odb: prepare `struct odb_transaction` to support more sources Justin Tobler
2026-01-29 11:24 ` Patrick Steinhardt
2026-01-29 19:41 ` Justin Tobler
2026-01-28 23:45 ` [PATCH 4/4] odb: transparently handle common transaction behavior Justin Tobler
2026-01-29 11:24 ` Patrick Steinhardt
2026-02-03 0:09 ` [PATCH v2 0/4] odb: support ODB source specific transaction handling Justin Tobler
2026-02-03 0:09 ` [PATCH v2 1/4] odb: store ODB source in `struct odb_transaction` Justin Tobler
2026-02-03 0:10 ` [PATCH v2 2/4] object-file: rename transaction functions Justin Tobler
2026-02-03 0:10 ` [PATCH v2 3/4] odb: prepare `struct odb_transaction` to become generic Justin Tobler
2026-02-03 15:54 ` Toon Claes
2026-02-03 16:46 ` Justin Tobler
2026-02-03 22:54 ` Junio C Hamano
2026-02-04 6:26 ` Patrick Steinhardt
2026-02-04 17:15 ` Justin Tobler
2026-02-04 10:31 ` Karthik Nayak
2026-02-04 17:38 ` Justin Tobler
2026-02-05 11:20 ` Karthik Nayak
2026-02-03 0:10 ` [PATCH v2 4/4] odb: transparently handle common transaction behavior Justin Tobler
2026-02-04 10:34 ` Karthik Nayak
2026-02-04 17:50 ` Justin Tobler
2026-02-05 11:22 ` Karthik Nayak
2026-02-03 1:16 ` [PATCH v2 0/4] odb: support ODB source specific transaction handling Junio C Hamano
2026-02-04 6:25 ` Patrick Steinhardt
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=aXu4nttn-SWcMmLL@denethor \
--to=jltobler@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox