Re: [PATCH v3 2/9] builtin/clone: defer setup of the object database

> On 26/09/07 10:25AM, 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.
> > 
> > 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.
> > 
> > Defer creation of the object database until after we have resolved the
> > URI.
> > 
> > Note that this also requires us to defer the call to `setup_reference()`
> > until after we have created the object database. While you might think
> > that this function has something to do with references ("refs/*"), it is
> > in fact responsible for setting up alternates. Consequently, we can only
> > call it after we have created the object database already.
> 
> Ah ok, so now that we are deferring ODB creation a bit further, we need
> to also move ref DB creation to afterwards too. Makes sense.