From: Patrick Steinhardt <ps@pks.im>
To: Justin Tobler <jltobler@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/8] odb: resolve relative alternative paths when parsing
Date: Tue, 9 Dec 2025 09:04:20 +0100 [thread overview]
Message-ID: <aTfYBGr-0SIDinYF@pks.im> (raw)
In-Reply-To: <kz2eftlrmaxpxjybhjwqlewy3dx44sdznimzs6reoqtev4qtox@hl3s2gxz3sk2>
On Mon, Dec 08, 2025 at 08:09:30PM -0600, Justin Tobler wrote:
> On 25/12/08 09:04AM, Patrick Steinhardt wrote:
> > Parsing alternates and resolving potential relative paths is currently
> > handled in two separate steps. This has the effect that the logic to
> > retrieve alternates is not entirely self-contained. We want it to be
> > just that though so that we can eventually move the logic to list
> > alternates into the `struct odb_source`.
>
> Naive question: is the intent here to eventually move alternate ODB
> sources under the primary ODB source? Or just to record the alternate
> dir info in the ODB source?
Not only the primary ODB source, but into ODB sources in general as
alternates are recursive by nature.
The problem I am trying to solve is that ODB sources may not even have a
filesystem-local directory, but the way we use alternates recursively
very much assumes they do. I don't want to treat "files" sources
specially though and only recursively add their alternates. Instead, I
want to move the logic of enumerating alternates into the source so that
every source can have a different way of enumerating them that may or
may not use the filesystem.
> > Move the logic to resolve relative alternative paths into
> > `parse_alternates()`. Besides bringing us a step closer towards the
> > above goal, it also neatly separates concerns of generating the list of
> > alternatives and linking them into the object database.
> >
> > Note that we ignore any errors when the relative path cannot be
> > resolved. This isn't really a change in behaviour though: if the path
> > cannot be resolved to a directory then `alt_odb_usable()` still knows to
> > bail out.
> >
> > While at it, rename the function to `odb_add_source()` to more clearly
> > indicate what its intent is and to align it with modern terminology.
>
> Alternates are indeed just additional ODB sources appended to the
> sources list. IIUC though, doesn't this function only add alternate
> sources? If so, maybe it would be better to use
> `odb_add_alternate_source()`?
Hm, yeah, I think you're right. We still have the recursive nature at
the end of this series, so let's call it accordingly.
Patrick
next prev parent reply other threads:[~2025-12-09 8:04 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-08 8:04 [PATCH 0/8] Refactor handling of alternates to work via sources Patrick Steinhardt
2025-12-08 8:04 ` [PATCH 1/8] odb: refactor parsing of alternates to be self-contained Patrick Steinhardt
2025-12-08 22:37 ` Justin Tobler
2025-12-08 8:04 ` [PATCH 2/8] odb: resolve relative alternative paths when parsing Patrick Steinhardt
2025-12-09 2:09 ` Justin Tobler
2025-12-09 8:04 ` Patrick Steinhardt [this message]
2025-12-09 18:06 ` Justin Tobler
2025-12-10 5:53 ` Patrick Steinhardt
2025-12-08 8:04 ` [PATCH 3/8] odb: move computation of normalized objdir into `alt_odb_usable()` Patrick Steinhardt
2025-12-09 2:34 ` Justin Tobler
2025-12-09 8:04 ` Patrick Steinhardt
2025-12-08 8:04 ` [PATCH 4/8] odb: adapt `odb_add_to_alternates_file()` to call `odb_add_source()` Patrick Steinhardt
2025-12-08 8:04 ` [PATCH 5/8] odb: remove mutual recursion when parsing alternates Patrick Steinhardt
2025-12-09 17:31 ` Justin Tobler
2025-12-08 8:04 ` [PATCH 6/8] odb: drop forward declaration of `read_info_alternates()` Patrick Steinhardt
2025-12-08 8:04 ` [PATCH 7/8] odb: read alternates via sources Patrick Steinhardt
2025-12-09 17:49 ` Justin Tobler
2025-12-10 5:54 ` Patrick Steinhardt
2025-12-08 8:04 ` [PATCH 8/8] odb: write " Patrick Steinhardt
2025-12-10 15:32 ` [PATCH v2 0/8] Refactor handling of alternates to work " Patrick Steinhardt
2025-12-10 15:32 ` [PATCH v2 1/8] odb: refactor parsing of alternates to be self-contained Patrick Steinhardt
2025-12-10 15:32 ` [PATCH v2 2/8] odb: resolve relative alternative paths when parsing Patrick Steinhardt
2025-12-10 15:32 ` [PATCH v2 3/8] odb: move computation of normalized objdir into `alt_odb_usable()` Patrick Steinhardt
2025-12-10 15:32 ` [PATCH v2 4/8] odb: adapt `odb_add_to_alternates_file()` to call `odb_add_source()` Patrick Steinhardt
2025-12-11 7:21 ` SZEDER Gábor
2025-12-11 9:29 ` Patrick Steinhardt
2025-12-10 15:32 ` [PATCH v2 5/8] odb: remove mutual recursion when parsing alternates Patrick Steinhardt
2025-12-10 15:32 ` [PATCH v2 6/8] odb: drop forward declaration of `read_info_alternates()` Patrick Steinhardt
2025-12-10 15:32 ` [PATCH v2 7/8] odb: read alternates via sources Patrick Steinhardt
2025-12-10 15:32 ` [PATCH v2 8/8] odb: write " Patrick Steinhardt
2025-12-10 20:00 ` [PATCH v2 0/8] Refactor handling of alternates to work " Justin Tobler
2025-12-11 5:01 ` Patrick Steinhardt
2025-12-11 9:30 ` [PATCH v3 " Patrick Steinhardt
2025-12-11 9:30 ` [PATCH v3 1/8] odb: refactor parsing of alternates to be self-contained Patrick Steinhardt
2025-12-11 9:30 ` [PATCH v3 2/8] odb: resolve relative alternative paths when parsing Patrick Steinhardt
2025-12-11 9:30 ` [PATCH v3 3/8] odb: move computation of normalized objdir into `alt_odb_usable()` Patrick Steinhardt
2025-12-11 9:30 ` [PATCH v3 4/8] odb: stop splitting alternate in `odb_add_to_alternates_file()` Patrick Steinhardt
2025-12-11 9:30 ` [PATCH v3 5/8] odb: remove mutual recursion when parsing alternates Patrick Steinhardt
2025-12-11 9:30 ` [PATCH v3 6/8] odb: drop forward declaration of `read_info_alternates()` Patrick Steinhardt
2025-12-11 9:30 ` [PATCH v3 7/8] odb: read alternates via sources Patrick Steinhardt
2025-12-11 9:30 ` [PATCH v3 8/8] odb: write " 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=aTfYBGr-0SIDinYF@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=jltobler@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;
as well as URLs for NNTP newsgroup(s).