Pushing to Mozilla hg servers directly from git

I’ve been using git for a few years for doing Mozilla work, which has caused me to have to go through a painful workflow every single time that I push code to inbound.  Now, glandium has written this awesome tool that finally enables me to use git push to push an actual set of git commits to the hg servers, directly, without running Mercurial.  My existing workflow for pushing involves exporting textual diffs from git, and importing the file into Mercurial, and deal with the conflicts myself, etc.  I often get it wrong and end up pushing half-patches that don’t compile.  Even when that doesn’t happen, I find the interaction with Mercurial quite draining.  Mercurial is so much slower in very common every day operations and sitting there and waiting for it makes me restless.  If any of these resonates with you, glandium has written a blog post which can help you get started.  Please go and read it.

You need to do the initial clone through git-remote-hg.  If you already have a clone of gecko-dev, you can safely fetch hg:: remotes inside there.  For example, you can fetch hg::ssh://hg.mozilla.org/integration/mozilla-inbound for rebasing and pushing to inbound through there.  To make things easier, you can gradually move your work based on branches from git-remote-hg and slowly migrate away from the gecko-dev based branches.

One interesting side-note: I measured the amount of storage that my local clone’s .git directory takes versus that of an hg mozilla-central clone.  Note that my local git repo contains both the entire gecko-dev history (which includes the CVS history) and the repo created by git-remote-hg.  Its size is 2GB, versus an 1.8GB .hg directory of just mozilla-central.  Given that I have accumulated tons of local hg clones from all of our central and release and project branches, I’m really looking forward to the disk space saving when I finally decide to delete most (all?) of my local hg clones!  🙂

Tagged with: , ,
2 comments on “Pushing to Mozilla hg servers directly from git
  1. glandium says:

    FWIW, I wrote git-remote-hg with the goal of being as fast as possible to clone, and I’d expect it to be quick enough to clone for people not to have to clone from github first. Especially, since there’s more data to download from github than there is from hg.mozilla.org. Although, things are not optimal yet, considering most of the work happens after the download is over, but I have plans to move part of that work to happen during the download.
    Note that Snorp told me his clone was taking hours, which it shouldn’t have been, and I found why that was the case and fixed it. This probably happened after you cloned.

    That being said, your github repository lacks the most important refs (refs/remote-hg/* and refs/notes/remote-hg/*), and as such, still requires a full clone from mercurial… Also, depending on when you did your clone, and whether you did it with core.ignorecase set to true (you’re on a mac, right?), your clone might be corrupted, although recent versions of git-remote-hg barf about that. You can check your clone is fine with git hgdebug fsck –manifests (note that will likely take an hour or more) if you’re using the current master tip of git-remote-hg.

    • ehsan says:

      Ah, great points! I think at this point the best option is for me to remove that repo from github and let people clone locally. I edited the post accordingly. Thanks for pointing this out!