On Wed, Apr 02, 2014 at 01:29:13AM +0200, Max Horn wrote:
> On 01.04.2014, at 15:15, Jeff King <p...@peff.net> 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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to