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

[Junio C Hamano <gitster@pobox.com>]

"Yin Ping" <pkufranky@gmail.com> 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.