On Wed, Apr 02, 2014 at 01:29:13AM +0200, Max Horn wrote: > > On 01.04.2014, at 15:15, Jeff King <peff@xxxxxxxx> wrote: > > > On Tue, Apr 01, 2014 at 10:07:03PM +0900, Mike Hommey wrote: > > > >>> For my own curiosity, how does this differ from what is in > >>> contrib/remote-helpers/git-remote-hg? > >> > >> contrib/remote-helpers/git-remote-hg does a local mercurial clone > >> before doing the git conversion. While this is not really a problem > >> for most mercurial projects, it tends to be slow with big ones, > >> like the firefox source code. What I'm aiming at is something that > >> can talk directly to a remote mercurial server. > > > > Ah, that makes sense. Thanks for explaining. > > > Hm, myself, I am not quite convinced. Yes, there is an overhead, but > it is one-time (well, the space overhead is not, but Mike only > mentioned time, not space). I didn't mention it, but it definitely is a factor. As for the performance factor, it certainly is more than a one-time overhead. > I wonder if it is really worth the effort > to start yet another project on this... Moreover, I don't see a > fundamental reason why one could not modify git-remote-hg to work this > way. The way git-remote-hg works is fundamentally different to how one can directly get and push stuff to a remote mercurial server. As such, there is not much value in the current git-remote-hg code for that purpose. Also, I'm currently prototyping something to see whether what I think should work really works. Starting from the current git-remote-hg code would add useless constraints to the prototype. Mike -- 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