Hi, On Sat, 23 Sep 2006, Petr Baudis wrote: > Hi! > > Dear diary, on Sat, Sep 23, 2006 at 07:54:10PM 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 07:23:01PM CEST, I got a letter > > > where Johannes Schindelin <Johannes.Schindelin@xxxxxx> said that... > > > > 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. > > So how should the proxy repository be set up at the server side? I can > just imagine a cronjob periodically sweeping the repositories and > populate the proxy repository with new stuff (refs and objects) from > those. > > Looking at what you wrote again, you talk about fetching all those > branches _into_ one proxy repository. Perhaps we misunderstand each > other. This patch is not about the "into" part, it is about being able > to fetch _FROM_ _multiple_ repositories. Indeed, I misunderstood. Hmmm. Did you test if this makes things better? If so, could you test with one proxy repo on the server? I bet that this would be even more efficient. And the proxy repo would be updated best by a hook, not a cronjob. The thing is, your patch optimizes for a very special case, which special case IMHO should be handled differently to begin with. 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