Patrick Steinhardt <ps@xxxxxx> writes: > We're about to change git-clone(1) so that we set up the reference > database at a later point. This change will cause git-remote-curl(1) to > not detect the repository anymore due to "HEAD" not having been created > yet at the time it spawns, and thus causes it to error out once it is > asked to fetch the references. > > We can address this issue by trying to re-discover the Git repository in > case none was detected at startup time. With this change, the clone will > look as following: > > 1. git-clone(1) sets up the initial repository, excluding the > reference database. > > 2. git-clone(1) spawns git-remote-curl(1), which will be unable to > detect the repository due to a missing "HEAD". > > 3. git-clone(1) asks git-remote-curl(1) to list remote references. > This works just fine as this step does not require a local > repository > > 4. git-clone(1) creates the reference database as it has now learned > about the object format. Sorry, but I am not sure I understand this step. I assume you mean by "the object format" what hash function is used to index the objects (which can be learned from the remote "origin" in step 2 and we can choose to use the one they use), not what ref backend is used (which is purely a local matter and we do not need to know what is used at the "origin"). Why do we need to wait initializing ref backend until we learn what hash is being in use? > 5. git-clone(1) asks git-remote-curl(1) to fetch the remote packfile. > The latter notices that it doesn't have a repository available, but > it now knows to try and re-discover it. > > If the re-discovery succeeds in the last step we can continue with the > clone. OK.
