Re: Dose git-fetch need --reference option like git-clone?

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 11, 2007, 08:36 UTC
Message-ID: <7vsl3dgovv.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <46dff0320711110009y713c7d38q7b1457c92daecef6@mail.gmail.com>

"Yin Ping" <pkufranky@gmail.com> writes:

Show 6 quoted lines

> 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.