git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).