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