From: Junio C Hamano Date: Tue, 25 Mar 2014 22:17:07 GMT Subject: Re: Borrowing objects from nearby repositories Message-ID: In-Reply-To: Junio C Hamano writes: > Ævar Arnfjörð Bjarmason writes: > >>> 1) Introduce '--borrow' to `git-fetch`. This would behave similarly >> to '--reference', except that it operates on a temporary basis, and >> does not assume that the reference repository will exist after the >> operation completes, so any used objects are copied into the local >> objects database. In theory, this mechanism would be distinct from >> --reference', so if both are used, some objects would be copied, and >> some objects would be accessible via a reference repository referenced >> by the alternates file. >> >> Isn't this the same as git clone --reference --no-hardlinks >> ? >> >> Also without --no-hardlinks we're not assuming that the other repo >> doesn't go away (you could rm-rf it), just that the files won't be >> *modified*, which Git won't do, but you could manually do with other >> tools, so the default is to hardlink. > > I think that the standard practice with the existing toolset is to > clone with reference and then repack. That is: > > $ git clone --reference git://over/there mine > $ cd mine > $ git repack -a -d > > And then you can try this: > > $ mv .git/objects/info/alternates .git/objects/info/alternates.disabled > $ git fsck > > to make sure that you are no longer borrowing anything from the > borrowee. Once you are satisfied, you can remove the saved-away > alternates.disabled file. Oh, I forgot to say that I am not opposed if somebody wants to teach "git clone" a new option to copy its objects from two places, (hopefully) the majority from near-by reference repository and the remainder over the network, without permanently relying on the former via the alternates mechanism. The implementation of such a feature could even literally be "clone with reference first and then repack" at least initially but even in the final version.