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. > > 2. Git does not store on-disk deltas between objects that are not in > > the same packfile. So you'd only be able to delta against an object > > that came in the same stream (or you'd have to "fix" the packfile > > on disk by adding an extra copy of the delta base, but that > > probably eliminates any savings). > > Arguably, this would make the most difference on initial clone of big > projects, or large incremental updates (like, after a few weeks), which > would use a single pack anyways. Yeah. The nice thing is that this can be an opportunistic optimization. If the delta base is part of the same output stream, then send the delta. Otherwise, you can always fall back to reconstructing and sending the full object yourself. > It seems to me fast-import keeps a kind of human readable format for its > protocol, i wonder if xdelta format would fit the bill. That being said, > I also wonder if i shouldn't just try to write a pack on my own... The fast-import commands are human readable, but the blob contents are included inline. I don't see how sending a binary delta is any worse than sending a literal binary blob over the stream. -Peff -- 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