Hi, On Sat, 23 Sep 2006, Petr Baudis wrote: > Dear diary, on Sat, Sep 23, 2006 at 07:23:01PM CEST, I got a letter > where Johannes Schindelin <Johannes.Schindelin@xxxxxx> said that... > > On Sat, 23 Sep 2006, Petr Baudis wrote: > > > > > Dear diary, on Sat, Sep 23, 2006 at 06:57:36PM CEST, I got a letter > > > where A Large Angry SCM <gitzilla@xxxxxxxxx> said that... > > > > Petr Baudis wrote: > > > > >You still need to pass git-fetch-pack some URL in addition to the > > > > >repositories - it is used only for git_connect(), the purpose is that > > > > >repositories must be local directories so if you want to talk remote, you > > > > >need to do something like > > > > > > > > > > git-fetch-pack git://kernel.org/pub/scm/git/git.git > > > > > --repo=/pub/scm/git/git.git master next > > > > > --repo=/pub/scm/cogito/cogito.git master > > > > > > > > > > > > > Can't this be done with a simple wrapper around git-fetch* ? > > > > > > The point is that that is too slow (the difference is noticeable > > > especiall in the case there is no new stuff ready), you need to create a > > > connection and do whole lot of work for each of the repositories. > > > > I still firmly believe that it would be way more efficient to fetch all > > those branches into _one_ proxy repository. Especially since you can reuse > > the objects with an alternate, which has an additional benefit over your > > approach. > > Huh? You can reuse the objects with my approach as well. Actually, it > is automagically done so. > > With proxy repository, you would still need a server-side setup to > maintain that repository, and specialized client-side porcelain to fetch > from it. My approach initially requires some core changes (which aren't > very pretty as it is but are not very fundamental or logically intrusive > either) but in the longer run it pays off since you don't need a > convoluted server-side setup for that. No, you do not need _any_ server-side setup. And you do not need any specialized client-side porcelain other than a script, which just does the job. The point is, your changes are not only intrusive, they are unnecessary. You can even declare the first repository as the proxy. Sketch of script: - find which branches are wanted at all, - do the fetch (of all wanted branches) in the first repository, storing the refs under refs/multi/, - for each repository - ensure that the first repo is given as alternative - store the branches this repo wants (you only need to update the refs, since you have all the objects) This is not particularly complicated, is it? Ciao, Dscho - 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