Re: [PATCH v2 1/8] builtin/clone: defer setup of the object database

On 26/08/31 12:02PM, Patrick Steinhardt wrote:

When cloning a repository we defer initialization of the reference
database. This is because we don't yet know all details required for us
to initialize the refdb in the first place. Most importantly, what we
are missing is information about the object hash.

We don't do the same thing for the object database yet, but here we
essentially have the same problem. While the "files" database does not
need any information about the object format at creation time, alternate
backends are likely to require that information so that they can
properly set up their data structures.

Ok, so if we want to move the writing of alternates to happen at ODB
creation time, this information will be needed ahead of time.

Besides this forward-looking future proofing though, we also have a
second use case for deferring initialization of the object database,
namely alternates. When initializing the object database we do not yet
know whether we'll need alternates or not because this depends on the
repository we're about to clone from. If it is a local repository and
the user has passed "--refernce{,-if-able}", then we will end up writing
alternates into the object database.

The ugly part though is that we cannot determine where the repository is
getting cloned from before it has been initialized. While we of course
already have access to the user-provided URI, that URI can be very well
rewritten via "url.<base>.insteadOf". We can of course read the global-
and system-level configuration to resolve it. But we explicitly resolve
the URI a second time after we have initialized the repository because
it can happen that we copy a ".git/config" over from our templates, and
that file may cause us to rewrite the path.

In a subsequent commit though we'll start to write alternates as part of
the repository initialization, so we'll need to have the URI properly
resolved before we can initialize the object database. This is ugly, but
as mentioned above it makes sense for us to defer its initialization
anyway so that we also know about the object hash already.

Ok.

Ok, now we skip the initializing the ODB during init_db in favor of
delaying it to after we have the required config info. This makes sense
to me, but IMO the `init_db()` interface has grown quite awkward with
these "skip" flags. It appears that there are only two callers of
`init_db()` which makes me wonder if it would be simpler to just require
them to explicitly set up the ref DB and ODB.

We now explicitly create the object database here.

+	if (option_required_reference.nr || option_optional_reference.nr)
+		setup_reference();

Any reason the reference setup is also further deferred here?

-Justin