From: Junio C Hamano Date: Sun, 11 Nov 2007 08:36:20 GMT Subject: Re: Dose git-fetch need --reference option like git-clone? Message-ID: <7vsl3dgovv.fsf@gitster.siamese.dyndns.org> In-Reply-To: <46dff0320711110009y713c7d38q7b1457c92daecef6@mail.gmail.com> "Yin Ping" writes: > If I already have a cloned remoteA on local machine (say > /path/to/remoteACloned), I want to do following to reduce the net > traffic as git-clone: > git fetch --reference /path/to/remoteACloned remotedA > > Is this reasonable? Or is there already a resolution for this case? Resolution, meaning "No, that's not a good thing and we refuse to support such an option"? No, there is no such thing. I think what you are talking about is a reasonable thing to want. It would have been easier to hack in back when git-fetch was a script, but now you would need to work a bit harder in the C code. On the other hand, however, I suspect the resulting code would be cleaner without having to actually create and delete temporary refs in refs/reference-tmp/ namespace but fake them only in-core, with a proper transport API enhancements. But if you only want a quick-and-dirty workaround, you can manually do refs/reference-tmp and objects/info/alternates dance that is done by git-clone before running a git-fetch from such "nearby" remote. I strongly suspect that an approach not to use temporary refs on the filesystem would be needed for robustness if we were to do this for real inside git-fetch as a real solution, so that we would not leave them behind when interrupted. This is not such a big deal for git-clone which knows it always starts from a void and cleaning up the mess is not a big issue, but matters for the use of git-fetch under discussion, which _will_ work inside an already initialized repository.