Mike Hommey <mh@xxxxxxxxxxxx> writes: > It would probably be reasonable to have this on git-remote. Anyways, you > can easily do it yourself by editing .git/objects/info/alternates and > adding /path/to/remoteACloned in it. You can happily git fetch after > that. Not really. There are two parts in the --reference dance git-clone plays: - After the reference clone is done, obviously because you are avoiding to actually transfer the data, you need to set up alternates to permanently borrow from the reference repository. - Because the fetch/clone procedure considers an object that is locally accessible (either it locally exists, or exists in an alternate object store) "complete" (meaning, there is no need to fetch the objects that are reachable from it) ONLY when it is reachable from one of the refs in the repository, the above alone would not prevent fetch/clone from actually transferring the objects. For this reason, git-clone copies the refs that exist in the reference repository as temporary refs. This ensures that the objects that the clone borrows from the reference repository are considered "complete" during the clone process. The original design of git differenciated the object store (that is, .git/objects/) and a repository (.git). A repository has an object store associated with it, but the design allowed an object store to be shared among multiple repositories by symlinking. This is why alternates point at objects/ directory of the reference repository, not one level above. Today, no git tool creates such a "shared object store" layout, so if the original design were "an object store belongs only to one repository, and the ../refs directory relative to it always is the only set of refs that defines the completeness of the objects within it. No sharing of object store across repositories using symlink is allowed", we could redefine the completeness rule to also follow the alternates and doing so would eliminate the need for the latter "temporary ref" trick git-clone plays. But until we officially declare that a set of old repositories that uses the "shared object store" layout are not supported (and give a reasonably migration path), we unfortunately cannot do so. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
